To automate a set of tasks, you need to create workflows in your GitHub repository. GitHub looks for YAML files inside of the .github/workflows directory.
Events like commits, the opening or closing of pull requests, or updates to the project’s wiki, trigger the start of a workflow. For a complete list of available events, refer to this documentation.
Workflows are composed of jobs, which run concurrently by default. Each job should represent a separate part of your workflow. For example, you could have one job for running your tests, another for releasing your software, and a third for deploying to your production environment.
You can configure jobs to depend on the success of other jobs in the same workflow. For example, failing tests can prevent deploying to production.
Jobs contain a list of steps, which GitHub executes in sequence. A step can be a set of shell commands or an action, which is a pre-built, reusable step implemented either in TypeScript or inside a container. Some actions are provided by the GitHub team, while the open-source community maintains many more. The GitHub Marketplace keeps a catalog of known open-source actions.
Here is a sample workflow that uses the actions/checkout action and runs the docker build command to automatically build a container image when changes are pushed to the master branch:
To learn more about how to write workflows, follow the tutorial linked at the end of this article.
The answer is, as always: it depends.
If you are already using GitHub to host your project’s source code, getting started with GitHub Actions is effortless. The fact that it integrates fully with the entire GitHub ecosystem means your team can double down on using the platform as a significant part of your software development process.
GitHub Actions is free for all open-source projects, and private repositories get up to 2000 minutes per month before being billed anything. For smaller projects, this means being able to take full advantage of automation from the very beginning at no extra cost. You can even use the system for free forever if you use self-hosted runners.
While the community-driven Marketplace has immense potential, many actions remain to be built by the likes of you and me. In larger organizations, developing custom actions and sharing them across teams can significantly scale down the amount of work required to build and maintain workflows across projects.
However, one feature I have personally found lacking is the ability to trigger specific jobs manually. Some teams prefer that deployments to production require human intervention, be it only a click. GitHub Actions does not yet provide a built-in option for this.
Developers can adapt their workflow so that only tagged commits result in production deployments, for example. While GitHub is encouraging teams to adopt the common practice of continuous deployment, some may not wish to make that leap just yet.
Overall, my opinion is that GitHub Actions is worth a try. Whether this is the automation system best suited for your team depends on your specific needs.
To get you started with GitHub Actions, Padok provides a hand-on tutorial where you can build a GitHub action workflow that automatically builds, tests, releases, and deploys a simple microservice. The tutorial is available on GitHub!
In addition to this tutorial, I am giving a live online introduction [in French] to using GitHub Actions for CI/CD. The training session is on Thursday, April 30th at noon, Paris time. Register for the event below 👇