What is Github Actions?
Github Actions was released at the end of last year and it is a tool that can help automate the entire development workflow within Github. This means that you can do code version control, review, test, build, distribute, and much more and manage everything on Github. Github Actions basically does what previous CI tools like Jenkins, Travis CI, or CircleCI have been doing to some degree, except on Github. Even in terms of supported languages, it currently supports Node.js, Python, Java, PHP, Ruby, C/C++, .Net, Android, and iOS, and the list is projected to continue to grow.
With Actions, you can use codes to manage your workflow and to make adjustments easily. The greatest appeal lies in that it provides a single unified environment to work in. While Github Actions has a variety of different features, let’s explore the matrix, that allows multiple version controls asynchronously. The following example is from Github's documentation.
This allows multiple versions of Node.js and OSes to install npm parallelly to build and to test. The result is immediately available in the action tab.
When Will the Action Occur?
Most of the times, an action occurs due to webhooks. Here, webhooks refer to events like a push or a pull request on Github, a comment on an issue, a new label, a change in milestones, and more. Furthermore, the users can not only use the webhooks provided by Github, but they can also use custom webhooks created by users.
Github Actions also supports scheduling. Using POSIX Crontab, users can schedule events starting from 5 minute intervals.
It can be executed using external dispatch as well.
on: repository_dispatchCost?
The opensource is free(TGIFree 🙆♂️), and if it is private, the cost is calculated in terms of minutes.
Notification
Additionally, even if a user does not register to receive notifications a user will receive the results of the corresponding workflow in the registered email.
A user can also use hooks to receive notifications in a messenger. Now that we have discussed the basic features, let’s write a workflow that is suitable for TOAST UI Grid.
Building a TOAST UI Grid Workflow
TOAST UI Grid is an opensource that is developed and maintained by NHN’s FE Development Lab. Now let’s assume that the reader is the maintainer for TOAST UI Grid. Someone posted a PR. It could be an outside contributor or it could be someone from the lab. There are a few tests that must be done before a PR is merged onto the work branch including code review. To list a few, we must check that
1. the coding style used in the edition is in accordance to that of the lab.
2. it passes the E2E tests written using cypress.
3. the build does not have any possible issues.
If a problem rises, we could have used Github’s branch mechanism to not merge it onto the main branch. Currently, such tasks are mostly done automatically by Jenkins that is set up locally. The following is a new workflow that can be handled easily by Github Actions.
Building the Workflow
The tests were conducted under a personal repository with tui.grid forked.
In order to make our configuration file, let’s explore the action tab. We can already see that many templates for different environments are provided for our convenience already.
Here, we can select the environment that we want to extend or we can build our own workflow. Let’s specify the aforementioned workflow in greater detail. We need to work in Node.js environment as we need to perform static analysis using ESLint and conduct tests using Cypress. (While there is a template that offers Cypress, but we decided to write it ourselves in node due to monorepo concerns. An issue has been filed, so the author will update once an issue has been addressed.)
Specifying the aforementioned workflow in greater detail
☑️ Test Preparation
1️. Select the Node Version
2️. Install npm globally
3️. package/toast-ui.gird npm install
️️️☑️ Analysis using ESLint
☑️ E2E test using Cypress
The entire flow is referred to as a workflow, and each task mentioned above is a job. The order in which the jobs are processed is known as the step. Now, let's actually write our workflow. It can easily be done by creating a yml file in the path .github/workflows/. (Creating a configuration file can be done in an editor, but personally, the author prefers using Github's web editor due to formatting and autocomplete features.)
Now, let’s examine the yml file.
The tests were conducted in 16.04 ubuntu as it had xvfb issues under 18.04.
Test
Let’s test that the workflow works as planned. In order to do so, we have made two different workflows trigger two different errors as examples. First, I have made a pull request with a line of code that does not abide by the eslint rules.
We can observe that the action has been performed as soon as the pull request has been made.
Under details, we can see where the issue was found like when we run analysis using ESLint. Next, let’s resolve the ESLint issue, and manipulate the cypress test so that the test fails. I have changed the value of column.spec.ts a little and made a pull request.
The workflow has made it through ESLint, but the column.spec.ts was caught. Each test produced red lines at where we expected them. We have built a simple workflow. We no longer needed to use Jenkins and relied on a few commands to process the tasks quickly. However, it still has unstabilities.
What unstabilities?
We tested the claim that the matrix can run parallel tests under different environments by testing using Cypress, but the tests all failed in different environments. There were some tests that stopped in the middle, and there were also tests that failed despite it being correct. (The problem seemed to be from running tests in parallel. When conducted individually, the tests pass, but at that point, there is not much to it.)
The tests finally passes when we specified the node versions, but intermittently, the tests failed. It was difficult to see where the tests failed because even when using the same code, it failed at different places, and if this problem continues, we may have to reconsider the validity of the previously passed tests. (The author will address it again if we find the reason in the comments.)
Closing Remarks
FE Development Lab intends to introduce Github Actions to TOAST UI Grid, and intend to automate not only the aforementioned workflow, but much more 💪. Github Actions is already being used for many large opensource projects. The feedbacks are being addressed at a quick pace, and many CI companies and tools have been reworked to work with Github Actions. Currently, the TOAST UI components are using a local jenkins to handle workflow because of reasons like Selenium. At this point, other management issues are taking tolls. The author looks to Github Action with hope as more CI implemented in many private environments or Github enterprise environments are to be supported. (As the Using Github Actions as a Real Estate Notification demonstrates, it can be more than a CI when used well with a scheduler.)
