#78 Github actions 101: All basics you need to know about Github actions

GitHub Actions is a powerful platform that allows you to automate, customize, and execute your software development workflows directly within your GitHub repository. Here are some key points about GitHub Actions:

1. CI/CD Automation: With GitHub Actions, you can build, test, and deploy your code from GitHub using world-class Continuous Integration (CI) and Continuous Deployment (CD) features.
2. Workflow Customization: Create customized workflows by combining various actions to perform specific tasks. These tasks can include CI, CD, packaging, and more.
3. YAML-Based Configuration: Define your workflows using YAML files. These files specify the steps, triggers, and conditions for your automated processes.
4. Event-Driven Execution: GitHub Actions can be triggered by specific events, such as code pushes, pull requests, or scheduled times. You can also set up workflows to respond to external events.
5. Hosted and Self-Hosted Runners: Choose between hosted runners provided by GitHub or set up your own self-hosted runners for executing workflows.
6. Matrix Builds: Define matrix builds to test your code across different environments, versions, or platforms.
7. Language Agnostic: GitHub Actions supports workflows in any programming language.
8. Community and Custom Actions: Discover and use existing community-contributed actions or create your own custom actions to extend the capabilities of your workflows.

Workflow terms

What is a Workflow?

• A workflow is a configurable automated process that runs one or more jobs.
• Workflows are defined using a YAML file checked into your repository.
• They can be triggered by events in your repository, manually, or on a defined schedule.
• Workflows reside in the .github/workflows directory within your repository.
• A repository can have multiple workflows, each performing different tasks.

According to this official documentation, there are 3 basic terms that you must know about Github Actions workflow that include in a workflow:

1. Event: An event is a specific activity in a repository that triggers a workflow run. This could be anything from a pull request being opened, an issue being created, or a commit being pushed to the repository. Events can also be triggered on a schedule, by posting to a REST API, or manually. In CI/CD terms, events are similar to triggers that initiate the build, test, and deployment processes. In short, these events can be:

• Events that occur in your workflow’s repository
• Events that occur outside of GitHub and trigger a repository_dispatch event on GitHub
• Scheduled times
• Manual

2. Runner: A runner is the environment where a job is executed. GitHub provides runners on Linux, Windows, and macOS virtual machines, but you can also host your own runners. Runners can be used to execute jobs defined in your workflows. In CI/CD terms, runners are similar to agents or build nodes that execute the tasks defined in the pipeline.

3. Job: A job is a set of steps that are executed on a runner. Jobs can run in parallel or sequentially, depending on how they are configured in the workflow. Each job runs in its own environment, which can be a virtual machine or a container. In CI/CD, jobs are comparable to individual tasks or stages in a pipeline, such as building the application, running tests, or deploying to a production environment. Jobs can depend on each other, allowing for complex workflows to be defined.

• Parallel jobs: Jobs in GitHub Actions run in parallel by default. This means that if you define multiple jobs in your workflow, they will execute simultaneously on separate runners. This is particularly useful for tasks that do not depend on each other, such as linting and testing, which can be run at the same time to save time and resources. Here’s an example of running jobs in parallel (In this example, the job1 and job2 jobs are defined to run on separate runners, allowing them to execute in parallel):

name: Github Actions parallel jobs (actions)
on:
  push:
    branches: [master]
jobs:
  job1:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Amazon-Test
        with:
          command: npm run amazon
          browser: chrome
          headless: true
          record: false
  job2:
    runs-on: ubuntu-latest
    steps:
      - name: Print the input name to STDOUT
        run: echo The username is ${{ inputs.username }}

• Sequential jobs: If you have jobs that depend on the completion of other jobs, you can configure them to run sequentially using the needs keyword. This ensures that a job only starts after the jobs it depends on have completed successfully. Here's an example of running jobs sequentially (In this example, the pass-secret-to-workflow job will only run after the pass-secret-to-action job has completed successfully):

name: Sequential Actions
on:
  push:
    branches: [master]
jobs:
  pass-secret-to-action:
    runs-on: ubuntu-latest
    steps:
    # passing the secret to an action
      - name: Pass the received secret to an action
        uses: ./.github/actions/my-action
        with:
          token: ${{ secrets.access-token }}

  # passing the secret to a nested reusable workflow
  pass-secret-to-workflow:
    runs-on: ubuntu-latest
    needs: pass-secret-to-action
    steps:
      - name: Pass the secret to a nested reusable workflow
        uses: ./.github/workflows/my-workflow
        with:
          token: ${{ secrets.access-token }}
        

Create an example workflow

GitHub Actions utilizes YAML syntax to define workflows. Each workflow is stored as an individual YAML file within your code repository, residing in a directory named .github/workflows . Let's create a simple workflow then!

The following workflow has 3 jobs: the setup, build, and test jobs run in series, with build and test being dependent on the successful completion of the job that precedes them:

1. In your repository, create the .github/workflows/ directory to store your workflow files.
2. In the .github/workflows/ directory, create a new file called learn-github-actions.yml and add the following code.

name: a-simple-workflow-example
on:
  push:
    branches: [master]
jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - run: ./setup_server.sh
  build:
    needs: setup
    runs-on: ubuntu-latest
    steps:
      - run: ./build_server.sh
  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: ./test_server.sh

3. Commit these changes and push them to your GitHub repository.

Let's break down this yaml file syntax:

• name : (optional) The name of the workflow as it will appear in the “Actions” tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
• on [push] : (optional) Specifies the trigger for this workflow. This example uses the push event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to branch master.
• jobs : Groups together all the jobs that run in the a-simple-workflow-example workflow.
• setup / build /test : Job name.
• runs-on: ubuntu-latest : Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub.
• steps : Groups together all the steps that run in the setup / build /test job. Each item nested under this section is a separate action or shell script.
• run: ./setup_server.sh : The run keyword tells the job to execute a command on the runner. The command ./setup_server.sh executes a shell script named setup_server.sh .
• needs: setup : If you have a job that must only run after another job has completed, you can use the needs keyword to create this dependency. If one of the jobs fails, all dependent jobs are skipped; however, if you need the jobs to continue, you can define this using the if conditional statement. Here, build and test being dependent on the successful completion of the job setup .

More workflow syntax for GitHub Actions can be found here.

When your workflow is triggered, a workflow run is created that executes the workflow. After a workflow run has started, you can see a visualization graph of the run’s progress and view each step’s activity on GitHub.

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click Actions.
3. In the left sidebar, click the workflow you want to see.
4. From the list of workflow runs, click the name of the run to see the workflow run summary.
5. In the left sidebar or in the visualization graph, click the job you want to see.
6. To view the results of a step, click the step.

Tadaa, now you have gained understanding of Github Actions basics. Let's discuss how you can test the workflow locally in the next blog post.