Migrating from GitLab CI/CD to GitHub Actions

Introduction

GitLab CI/CD and GitHub Actions both allow you to create workflows that automatically build, test, publish, release, and deploy code. GitLab CI/CD and GitHub Actions share some similarities in workflow configuration:

• Workflow configuration files are written in YAML and are stored in the code's repository.
• Workflows include one or more jobs.
• Jobs include one or more steps or individual commands.
• Jobs can run on either managed or self-hosted machines.

There are a few differences, and this guide will show you the important differences so that you can migrate your workflow to GitHub Actions.

Jobs

Jobs in GitLab CI/CD are very similar to jobs in GitHub Actions. In both systems, jobs have the following characteristics:

• Jobs contain a series of steps or scripts that run sequentially.
• Jobs can run on separate machines or in separate containers.
• Jobs run in parallel by default, but can be configured to run sequentially.

You can run a script or a shell command in a job. In GitLab CI/CD, script steps are specified using the script key. In GitHub Actions, all scripts are specified using the run key.

Below is an example of the syntax for each system:

job1:
  variables:
    GIT_CHECKOUT: "true"
  script:
    - echo "Run your script here"

jobs:
  job1:
    steps:
      - uses: actions/checkout@v2
      - run: echo "Run your script here"

Runners

Runners are machines on which the jobs run. Both GitLab CI/CD and GitHub Actions offer managed and self-hosted variants of runners. In GitLab CI/CD, tags are used to run jobs on different platforms, while in GitHub Actions it is done with the runs-on key.

Below is an example of the syntax for each system:

windows_job:
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

linux_job:
  tags:
    - linux
  script:
    - echo "Hello, $USER!"

windows_job:
  runs-on: windows-latest
  steps:
    - run: echo Hello, %USERNAME%!

linux_job:
  runs-on: ubuntu-latest
  steps:
    - run: echo "Hello, $USER!"

For more information, see "Workflow syntax for GitHub Actions."

Docker images

Both GitLab CI/CD and GitHub Actions support running jobs in a Docker image. In GitLab CI/CD, Docker images are defined with an image key, while in GitHub Actions it is done with the container key.

Below is an example of the syntax for each system:

my_job:
  image: node:10.16-jessie

jobs:
  my_job:
    container: node:10.16-jessie

For more information, see "Workflow syntax for GitHub Actions."

Condition and expression syntax

GitLab CI/CD uses rules to determine if a job will run for a specific condition. GitHub Actions uses the if keyword to prevent a job from running unless a condition is met.

Below is an example of the syntax for each system:

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"'

jobs:
  deploy_prod:
    if: contains( github.ref, 'master')
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to production server"

For more information, see "Expressions."

Dependencies between Jobs

Both GitLab CI/CD and GitHub Actions allow you to set dependencies for a job. In both systems, jobs run in parallel by default, but job dependencies in GitHub Actions can be specified explicitly with the needs key. GitLab CI/CD also has a concept of stages, where jobs in a stage run concurrently, but the next stage will start when all the jobs in the previous stage have completed. You can recreate this scenario in GitHub Actions with the needs key.

Below is an example of the syntax for each system. The workflows start with two jobs named build_a and build_b running in parallel, and when those jobs complete, another job called test_ab will run. Finally, when test_ab completes, the deploy_ab job will run.

stages:
  -