I guess you are familiar with the GitHub at this point. Is it more than a version control system to you? As you can see in the image, there is an
Actions tab which leads to the GitHub Actions feature. What is it, you may ask?
GitHub Actions is an automation platform that contains workflows, and the workflows can be triggered manually, on schedule, or based on different events. It can create a CI/CD pipeline to build, test and deploy your codebase. However, as a mature automation platform, it can run arbitrary system commands, so its capability is NOT limited to a CI/CD pipeline.
In my previous article Advanced GitHub Actions - Conditional Workflow, I dived into the advanced feature. This time, let's start from the ground and discussing the basic concepts of GitHub Actions.
GitHub Actions consists of 5 core components:
How are they related? An event triggers a workflow, which contains multiple jobs. A runner executes a job, and one job can have multiple actions. By the way, I'm not certain why one component is named action while the platform is already named GitHub Actions, that just sounds confusing. 🤦♂️
Whenever something happens, it is an event, literally. You may wonder what can be considered events in GitHub Actions, and here, we have 2 types of events.
These are the events within the scope of your repository. Some notable examples are creating a pull request and merging code. It can go to the atomic level of how you use GitHub on a daily basis. You can take a look at GitHub Docs to learn more about available events and their usage.
These are what happens outside of your repository. By using a webhook event called
repository_dispatch, you can trigger a specific workflow.
This is something "big" that you want to achieve, a configurable automated process defined by a
yaml file that resides in the
/.github/workflows folder. Do you want an end-to-end test process? It can be named
e2e workflow. An example of the MUI repository below might give you a better visualization of GitHub Actions workflow feature.
It is a virtual machine (Linux, Windows, Mac) with an application called GitHub Actions Runner running. A runner will run a job when a workflow is triggered. The runners can be either self-hosted for customizability or GitHub-hosted.
A job can specify its runner using a
runs-on property. As each job uses its own runner (fresh virtual machine), their environment data is isolated by default. However, you can share the data by explicitly passing variables or results between them.
Note: I find the definition of a runner to be confusing. In some places, its purpose is defined as to run a job, however, other places say it runs a workflow. I believe they mean the same thing (as defined above), but you can keep this in mind and double check if necessary.
"The runner is the application that runs a job from a GitHub Actions workflow. It is used by GitHub Actions in the hosted virtual environments, or you can self-host the runner in your own environment."
"A runner is a server that runs your workflows when they're triggered."
-- GitHub Docs
In GitHub Actions workflow, there are jobs that consist of sequential (and skippable) steps. You can think the job as a group of tasks to do in order to achieve a goal (workflow). Each step defines a specific operation to be executed, be it a script, an GitHub Actions action, or arbitrary system commands.
Due to a sequential nature, a step is dependent on the previous one. If a previous step modifies an environment, then the later steps are affected by the changes. If one step fails or execute an
exit command with a failed-signal, the workflow will be cancelled.
Hopefully this helps you learn more about components of GitHub Actions platform. This article is only a brief introduction to this massive feature. You can learn more about this by using an official GitHub Docs. That said, I think I will write some more articles to have a deeper dive into this feature.