How does GitHub Actions work? let’s start with the Basics
When I was given the task of setting up a GitHub Actions pipeline for a .NET console application, I had no idea where to start. This fear became even greater when I asked my seniors and none of them had any experience with the topic. My mistake was to start configuring/programming something that was not clear to me and so I went back to BASICS (understanding how, why and for what the heck haha), once I answered myself: How does GitHub Actions work? everything was easier because I started asking the right questions.
How does GitHub Actions work?
STEP A: A developer executes an event into the git repository.
STEP B: The runner that has been listening and waiting for an event from the git repository with the .yaml file
STEP C: Execute the jobs defined in the workflow from the .yaml file and
STEP D: Execute the tasks and send the executable to the server.
What is GitHub Actions?
GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows us to automate the build, test and deployment steps at pipeline. In order to start configuring a pipeline, it is required define a workflow; A GitHub Actions workflow can be triggered when an event occurs in your repository. The workflow that builds and test every push, pull request or other event can be configured depending on the project requirements. Likewise, there are reusable workflows for base projects at the official documentation in GitHub Docs that you can reuse and then customize.
GitHub Actions Components:
- Workflow: is a configurable automated process that will run one or more jobs. Workflows are defined in the .github/workflows directory in a repository, and repository can have multiple workflows, each of which can perform a different set of tasks (remember that if you don’t have this defined, it’s like saying that you don’t know what you are going to configure).
- Event: is a specific activity in a repository that triggers a workflow run. For a complete list of events that can be user to trigger workflows, use Events that trigger workflows.
- Jobs: is a set of steps in a workflow that is executed on the same runner. Each step is either a shell script that will be executed, or an action that will be run. Steps are executed in order and are dependent on each other. When a job takes a dependency on another job, it will wait for the dependent job to complete before it can run.
- Actions: is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task.
- Runners: is a server that runs your workflows when they are triggered. Each runner can run a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run the workflows, and each workflow run executes in a newly provisioned virtual machine.
My main contribution in this blog was to respond to: How does GitHub Actions work? and share with you the basic concepts and reference links I consider important. Let me know, if you would like more details or making a step-by-step tutorial in a future blog. Thanks for reading! any comment or suggestion is welcome. Psdt: Don’t forget it! Come back to basics :)
Important resources:
- GitHub Actions & inContact reusable acddevops repo: GitHub Actions Reusable Workflows
- Setup-dotnet & GitHub Actions: actions/setup-dotnet: Set up your GitHub Actions workflow with a specific version of the .NET core sdk
- Link to GitHub Docs about creating a starter workflow: Creating starter workflows for your organization — GitHub Docs
- Workflow syntax for GitHub Actions — GitHub Docs
