GitHub Action Workflow

I recently joined Program Equity, to contribute to the DevOps side, focusing specifically on GitHub Action workflow. Wondering what an action workflow is? According to Microsoft training module, GitHub Actions essentially are “packaged scripts to automate tasks in a software-development workflow in GitHub”. In simple words, this means that you write a script in the form of a YAML (or sometimes called yml) file and define when the action should be triggered; this set of instructions is known as a workflow. In summary, GitHub Actions are used for automating, customizing, and executing software development workflows.

In a nutshell, a Github Actions workflow is executed for each GitHub repository. While you can re-use actions, it is important to note that you still need to create an individual workflow using a YAML file. Additionally, GitHub Actions provides live logs and a visualized workflow execution, enabling you to identify code failures and troubleshoot errors through the longs. Keep in mind that the YAML file needs to be located under “.github/workflows” folder. The dot preceeding “.github” indicates that the folder is hidden.

Clicking on the Actions tab and selecting “Configure” will give you a template to start GitHub Actions

As mentioned, initiating the action workflow involve creating a repository in your GitHub account. Subsequently, navigate to the Actions tab and click on the “Configure” button under the Simple workflow section. By doing so, this step will give you a starting template forthe workflow.

The basic format of the YAML script for a GitHub Actions workflow includes:

1. “name” of the workflow
2. “on” which indicates when the workflow will be triggered. There are various types of workflow triggers, such as: push, pull_request, issue, page_build, release, etc. Refer to the documentation here for details.
3. “jobs”, indicates tasks to be executed within the workflow.

Example of a GitHub Action workflow. This workflow has two jobs; the first job uses GitHub Actions, while the second job uses GitHub Marketplace.

Ray Villalobos, in his course, highlighted that you can run up to 20 workflows in one repository. Moreover, each workflow can include multiple jobs. Jobs are differentiated by :

1. Id Label that must be unique. This must begins with numbers or letters that contains only alphanumeric characters, hyphen, or underscore.
2. By default, job runs in parallel, unless you specify it using “needs” attribute to indicate that a particular job should wait until another specified job is completed.
3. Additionally, each job can configured to run on different OS, such as: ubuntu-latest, ubuntu-18.04, windows-latest, windows-2019, macOS-latest, or macOS-10.14. The choices of OS is specified using an attribute called: “runs-on”. If you opt for the attribute “runs”, it signifies that the job will be executed within a container, such as Docker.

You can specify environment variables that apply to each job. The “env” variable works in the same way as local vs global variables in object-oriented programming (OOP). When you place this “env” variable under a specific job, it becomes a “local” variable for that job. However, if you place the variable at the same level as job, every jobs that doesn’t explicitly specify a local “env” will use the “global” env variable. Additionally, you have the options to set specific conditions for when running the job, using if condition. Otherwise, “env” variable is used to store the values needed when making API calls.

Example of “env” variable and how to use it when calling an API

Next, we have attributes called “steps”. This represent a sequence of tasks or a list of actions that you want the job to perform. You can leverage pre-existing actions provided by GitHub Actions, or explore options in the GitHub Marketplace, under the “steps” section. Additionally, you have the flexibility to create your own actions. The syntax for this involves using : ‘{owner}/{repo}@{ref}’ or ‘{owner}/{repo}/{path@{ref}’. The “ref” specifies the version you wish to utilize. To gain a better understanding of each action, please refer to the documentation, which can guide you in streamlining your work without re-inventing the wheel.

Furthermore, if you are involved in managing the process of building a website using workflows, you can use tools like gulp.js or webpack. If you want to learn more about gulp.js, you can check Ray’s video.

In the upcoming blog post, I want to showcase the ticket that I was working on, as part of the action-workflow team at ProgramEquity. Satoshi and I were collaborating to work on the same ticket, however, we decided to use different GitHub Actions and compared note. I will provide insights into what each actions does, as well as explain why Satoshi’s approach is better aligned with the specified requirement. If you are interested, you can follow Satoshi’s journey through his blog.