GitHub Actions: what it is and how to use
The code development process can be tedious. But what if you could remove some of this work off your chest? GitHub Actions may help.
Github Actions is a function recently introduced in Github that allows you to automate workflow. Now GitHub can take care of a number of processes that can be caused by various events: pushing code, creating a release or issues.
What can be done with Github Actions?
The possibilities are endless:
- continuous integration (software creation, testing and deployment);
- Npm-modules publication;
- Email or SMS notifications;
- and so on…
This is done using actions that can be defined in your or any public Github repository or in a Docker image.
After you login, you have access to creating your own workflows and actions.
You can easily access the GUI editor via the Actions tab, which will be added to your repositories as soon as such rights are granted.
How does GitHub Actions work?
Github Actions work using a customized workflow that contains actions, their relationships and dependencies.
Workflow
This parameter defines how actions should work, and the order of their execution.
When creating a new workflow, start with main. a file that is found in the .github/ repository directory.
|-- my-repo (repository)
| |** .github
| |** main.workflow
The main.workflow file contains any number of workflow and actions blocks in the prescribed order, and you can work with them in this file. Below is an example of a workflow with one workflow block and three actions block:
workflow "MYWORK" {
on = "EVENT"
resolves = "ACTION3"
}
action "ACTION1" {
uses = "docker://image1"
}
action "ACTION2" {
needs = "ACTION1"
uses = "docker://image2"
}
action "ACTION3" {
needs = "ACTION2"
uses = "docker://image3"
}
The above sequence is:
- the on keyword means a specific event (EVENT) that triggers a workflow (MYWORK);
- MYWORK calls the 3rd action (ACTION3) using the resolves keyword;
- ACTION3 requires ACTION2, which in turn requires ACTION1.
That’s why that actions are performed in the following order:
ACTION1 --> ACTION2 --> ACTION3
The action is initialized only after successful completion of all necessary conditions. If the resolves attribute is represented by an array of actions, they will be executed in parallel, as shown below:
workflow "IDENTIFIER" {
on = "EVENT"
resolves = ["ACTION1", "ACTION2"]
}
Actions
In the actions we determine which commands will be executed. They can be stored in a docker image, which can be accessed using the uses attribute. We can also ask to execute a specific command in the Docker image using the runs attribute. If this is not provided, the Dockerfile ENTRYPOINT statement will be executed. If a specific sequence of actions is needed, the needs attribute is used, as shown in the example above.
Environment variables
In actions, we can apply any environment variables through the env attribute. Secret variables, such as tokens, are provided in the secrets attribute. They must be installed in the workflow GUI in the Settings tab. We can also pass arguments to actions as a string or array, separated by commas using the args attribute.
When initializing an action, it is recommended to specify the version of this action using the Docker or SHA tag. This will prevent workflow disruption on “clumsy” update publishing.
Setting up actions using a GUI editor is even easier – drag the blue dot connector down to the workflow.
Add an action name in the Choose Action section and click the Use button. You can add other configuration parameters as shown below and click Done at the end.
Repeat these steps if you want to add additional actions to the workflow and link them to your liking. When you finish editing the workflow, click the Start commit button in the upper right corner.
Enter a commit comment, enter an email address, select a branch and click Propose new file.
The workflow commit makes it available for your branch. To enable workflow for the entire project, create a pull request for the master and merge it. To make sure workflow is working properly, open the Checks tab before merging.
Workflow restrictions
It is important to note that currently GitHub imposes the following restrictions on all workflows:
each workflow should be completed in no more than 58 minutes, including queuing and execution;
each workflow can handle up to 100 actions;
a repository is able to simultaneously execute no more than 2 workflows;
a task performed within one action cannot initiate other actions.
Conclusion
Github Actions is definitely worth the attention. It will simplify the development process and save time. If you do not want to poke around in all your configs, then Github provides a graphical interface where you can quickly accomplish all this. Customize your actions for any PL, using a variety of open source libraries.