Building a Block of a Github Actions

As described previously, workflow files use YAML syntax, which has either a .yml or .yaml file extension. If you’re new to YAML and want to learn more, see our section about YMAL. This workflow files must be stored in the .github/workflows directory of your repository.

Each workflow is defined in a separate YAML. We will introduce the building block of a workflow using Hello World Example:

name:
    Hello World package
on:
  push:
    branches: [ main ]
Jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

1. name

This is the name of the workflow and it is optional. GitHub will use this name to be displayed on the repository’s actions page.

name:
    Hello World package

2. on

The on field tells GHA when to run. For example, we can run the workflow anytime there’s a push or a pull on the main branch.

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

There are many events which can be used to trigger a workflow. You can explore them here.

3. jobs and steps

This block defines the core component of an Action workflow. Workflows are made of jobs. Every job also needs a specific host machine on which to run, the runs-on: field is how we specify it. The template workflow is running the build job in the latest version of Ubuntu, a Linux-based operating system.

jobs:
  build:
  runs-on: ubuntu-latest

We can also separate the build and test functions of our workflow into more than one job that will run when our workflow is triggered. Jobs are made of steps. These allow you define what to run in each job. There are three ways to define steps.

• With uses

• With run

• With name

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
  test:
    steps:
    - name: npm install
      run: |
        npm install
        npm test

The most basic action is actions/checkout@v3. This uses a GitHub provided action called checkout to allow the workflow to access the contents of the repository. All the steps of a job run sequentially on the runner associated with the job. By default, if a step fails, the subsequent steps of the job are skipped. Each run keyword represents a new process and shell in the runner environment. When you provide multi-line commands, each line runs in the same shell.

Providing a comprehensive guide of all the available options is beyond the scope of this overview, and instead, we would urge you to study official reference documentation and/or the CI configuration open-source projects references in the previous section.