In the previous post, we confirmed what CI/CD is, and that GitHub Actions is one of the representative services that provides it.

So how exactly does GitHub Actions provide CI/CD service?

Let's learn about GitHub Actions.

GitHub Actions is a CI/CD service that lets you build pipelines for automating builds, tests, and deployments.

It provides virtual machines for various OSes. This effectively gives you a dedicated CI/CD server. Users can configure the desired behavior via scripts, and that behavior runs on that server.

The criteria for triggering a workflow can also be flexibly specified. For example, a push occurring on a specific GitHub branch, or automatically running at a specific time.

This way, users can build a CI/CD pipeline. Of course it's a server, but unlike directly typing commands into a terminal like with AWS or Azure, there's a set way to describe behavior via yaml scripts. The detailed structure is covered below.

GitHub Actions is essentially a server, and users can specify its behavior by describing it in a script form.

The structure of GitHub Actions can be broadly divided into Workflows, Runners, Events, Jobs, Steps, and Actions. Let's briefly look at each element.

A workflow is a process that runs one or more jobs, and it's the top-level unit in GitHub Actions.

You can write a workflow as a yaml script. You can also select a desired template from the Actions tab of your GitHub repository.

YAML
name: CI

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

env:
  KEY: value

  

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Run a one-line script
        run: echo Hello, world!

      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

The script above is the Simple workflow template provided by GitHub Actions.

Every workflow is managed under the .github/workflows path. Placing a yaml script in that path is what GitHub recognizes as the structure.

You can think of a single yaml script as a single workflow.

Depending on how you configure it, you can also make it reusable from other workflows.

An event is the element that triggers a workflow run. You can apply an event to various activities possible within GitHub, such as a push occurring on a specific branch, or a PR being opened. Manual triggers are also possible.

In addition to activities within GitHub, you can also apply an event at specific time intervals.

YAML
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]
  workflow_dispatch:

The code above corresponds to the events portion of the full script.

You can express events in the script using the on keyword.

A job is a set of Steps run on a single runner. Once all assigned Steps have run, the job is considered complete.

Jobs run in parallel by default. Unless configured otherwise, all jobs run at the same time.

If you need to split work into build -> test -> deploy jobs and run them sequentially, you can add dependencies between jobs so that a given job only runs once a specific job has completed.

Using this kind of setup, you can apply various patterns, such as running the main jobs sequentially while adding a parallel job that sends a Slack notification whenever each job finishes.

YAML
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Run a one-line script
        run: echo Hello, world!

      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

The code above corresponds to the jobs portion of the full script.

You can see that a single job named build is declared.

A runner is the server that runs the workflow. You can specify the desired OS in the yaml script, and GitHub lets you choose not only Linux, but also Windows and MacOS.

One runner is assigned per Job, discussed below. Of course, the OS can also be specified per Job.

YAML
runs-on: ubuntu-latest

The code above corresponds to the runner portion of the full script.

It's declared under each job, and you can see that ubuntu-latest, the latest version of Ubuntu, is specified as the OS.

A step is a command run within a job. One or more steps can be declared under a job.

Each step can run a terminal command or script, and can also run an Action, discussed below.

To run a terminal command or script, use the run keyword; to run an Action, use the uses keyword.

Additionally, you can use a keyword called name to specify a title for each step, adding extra description to each task.

YAML
- name: Run a multi-line script
  run: |
    echo Add other actions to build,
    echo test, and deploy your project.

The code above corresponds to the steps portion of the full script.

It runs a basic terminal command using echo.

TXT
Add other actions to build,
test, and deploy your project.

The result of that step is as shown above.

Each step can also have either a success or failure outcome, and you can configure branching so that certain steps only run on success or failure.

An action is a custom application that packages complex tasks so they can be reused simply.

It lets you easily perform things like pushing to a specific repository, connecting via SSH, or deploying an NPM library.

These actions can take parameters via the with keyword, allowing customization to fit the user's needs.

YAML
- name: Testing the ssh-action
  uses: appleboy/ssh-action@v1.0.0
  with:
    host: 192.168.0.20
    username: username
    password: password
    port: 22
    script: echo Hello SSH World!

The script above is a usage example of one of the SSH actions, appleboy/ssh-action.

You can see the parameters needed for the SSH connection being entered.

The usage of each action depends on how the developer implemented it. Like typical libraries, they usually provide documentation describing usage, so refer to that.

You can check every available action on the GitHub Marketplace.

This post briefly covered GitHub Actions. Among its elements, some are relatively simple, while others are quite complex.

Since covering the key content of each element in a single post would make it far too long, I plan to split the main elements into separate posts, each explaining one topic.

The next post covers Events in GitHub Actions scripts.

Actually, Events was originally supposed to be post #2 and this was supposed to be post #3, but as I was writing, I realized I was talking about workflows and events without any mention of the structure of GitHub Actions at all.

It seemed like the right order would be to explain the overall elements first, then go into each detailed element, so I swapped the order.

Not many people have read this anyway, and it probably isn't cited anywhere, so it shouldn't be a big deal...

• [2024-06-09 03:35:27] Added content about the Jobs env