Monday 12 August 2024

Introduction to GitHub Actions





GitHub Actions (GHA): 
  • Workflow Automation Service offered by the GitHub
  • Allows you to automate all kinds of repository-related processes and actions
  • Service that offers various automations around the code that is stored on GitHub, around these repositories that hold that code.
  • Free for public repositories
Two main areas of processes that GitHub Actions can automate:
  • CI/CD processes (Continuous Integration/Continuous Delivery/Continuous Deployment) - methods for automating app development, testing, building and deployment
    • Continuous Integration is all about automatic handling code changes - integrating new code or code changes into an existing code base by building that code automatically. So that changed code by testing it automatically and by then merging it into existing code.
    • Continuous Delivery or deployment is about publishing new versions of your app or package or website automatically after the code has been tested and integrated
    • Example: After we make a change to the website code, we want to automatically upload and publish a new version of our website
    • GitHub Actions helps setting up, configuring and running such CI/CD workflows
    • It makes it very easy for us to set up processes that do automatically build, test, and publish new versions of our app, website, or package whenever we make a code change.
  • Code and repository management - automating:
    • code reviews
    • issue management

Key Elements


  • Workflows
  • Jobs
  • Steps


Workflows:
  • Attached to GitHub repositories
  • We can add as many workflows to GitHub repository as we wish
  • The first thing we build/create when setting up an automation process with GHA
  • Include one or more jobs
  • Built to set up some automated process that should be executed
  • Not executed all the time but on assigned triggers or events which define when a given workflow will be executed. Here are some examples of events that can be added:
    • an event that requires manual activation of a workflow
    • an event that executes a workflow whenever a new commit is pushed to a certain branch
  • Defined in a YAML file at this path: <repo_root>/.github/workflows/<workflow_name>.y[a]ml
Jobs:
  • Contain one or more steps that will be executed in the order in which they're specified
  • Define a runner
    • Execution environment, the machine and operating system that will be used for executing these steps
    • Can either be predefined by GitHub (runners for Linux, Mac OS, and Windows) or custom,  configured by ourselves
  • Steps will be executed in the specified runner environment/machine
  • If we have multiple jobs they run in parallel by default, but we can also configure them to run in sequential order, one job after another
  • We can also set up conditional jobs which will not always run, but which instead need a certain condition to be met.

Steps:
  • Define the actual things that will be done
  • Example:
    • download the code in the first step
    • install the dependencies in the second step
    • run automated tests in the third step
  • Belong to jobs, and a job can have one or more steps
  • And a step is either:
    • a shell script
    • a command in the command line that should be executed (e.g. for simple tasks), or 
    • an action, which is another important building block
      • predefined scripts that performs a certain task
      • We can build our own actions or use third party actions
  • We must have at least have one step,
  • Steps are then executed in order, they don't run in parallel, but instead, step after step
  • Steps can also be conditional

How to create a Workflow?


Workflow can be created in two ways:
  • directly on the remote, via browser
  • in the local repo, and then pushed to remote
If we use browser, we need to go to our repo's web page and then click on Actions tab. There we can select a default Workflow or choose some other template. Default workflow creates the following file:

my-repo/.github/workflows/blank.yml:

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "main" branch
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v4

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world!

      # Runs a set of commands using the runners shell
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.


---

No comments: