Migrating from GitLab CI/CD to GitHub Actions

Einführung

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-Konfigurationsdateien werden in YAML geschrieben und im Code-Repository gespeichert.
• Workflows umfassen einen oder mehrere Jobs.
• Jobs beinhalten einen oder mehrere Schritte oder einzelne Befehle.
• 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 beiden Systemen haben Jobs folgende Merkmale:

• Jobs contain a series of steps or scripts that run sequentially.
• Jobs can run on separate machines or in separate containers.
• Jobs werden standardmäßig parallel ausgeführt, können aber so konfiguriert werden, dass sie sequentiell laufen.

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 sind alle Skripte mit dem Schlüssel run spezifiziert.

Nachfolgend ein Beispiel für die Syntax in jedem 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.

Nachfolgend ein Beispiel für die Syntax in jedem 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.

Nachfolgend ein Beispiel für die Syntax in jedem System:

my_job:
  image: node:10.16-jessie

jobs:
  my_job:
    container: node:10.16-jessie

Weitere Informationen findest Du unter „Workflow-Syntax für 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.

Nachfolgend ein Beispiel für die Syntax in jedem 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.

Nachfolgend ein Beispiel für die Syntax in jedem 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:
  - build
  - test
  - deploy

build_a:
  stage: build
  script:
    - echo "This job will run first."

build_b:
  stage: build
  script:
    - echo "This job will run first, in parallel with build_a."

test_ab:
  stage: test
  script:
    - echo "This job will run after build_a and build_b have finished."

deploy_ab:
  stage: deploy
  script:
    - echo "This job will run after test_ab is complete"

jobs:
  build_a:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first."

  build_b:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first, in parallel with build_a"

  test_ab:
    runs-on: ubuntu-latest
    needs: [build_a,build_b]
    steps:
      - run: echo "This job will run after build_a and build_b have finished"

  deploy_ab:
    runs-on: ubuntu-latest
    needs: [test_ab]
    steps:
      - run: echo "This job will run after test_ab is complete"

Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

Scheduling workflows

Both GitLab CI/CD and GitHub Actions allow you to run workflows at a specific interval. In GitLab CI/CD, pipeline schedules are configured with the UI, while in GitHub Actions you can trigger a workflow on a scheduled interval with the "on" key.

For more information, see "Events that trigger workflows."

Variables and secrets

GitLab CI/CD and GitHub Actions support setting environment variables in the pipeline or workflow configuration file, and creating secrets using the GitLab or GitHub Enterprise Server UI.

For more information, see "Environment variables" and "Encrypted secrets."

Im Cache zwischenspeichern

GitLab CI/CD and GitHub Actions provide a method in the configuration file to manually cache workflow files.

Nachfolgend ein Beispiel für die Syntax in jedem System:

image: node:latest

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .npm/

before_script:
  - npm ci --cache .npm --prefer-offline

test_async:
  script:
    - node ./specs/start.js ./specs/async.spec.js

jobs:
  test_async:
    runs-on: ubuntu-latest
    steps:
    - name: Cache node modules
      uses: actions/cache@v2
      with:
        path: ~/.npm
        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
        restore-keys: v1-npm-deps-

GitHub Actions caching is only applicable to GitHub-hosted runners. Weitere Informationen findest Du unter „Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern“.

Artifacts

Both GitLab CI/CD and GitHub Actions can upload files and directories created by a job as artifacts. In GitHub Actions, artifacts can be used to persist data across multiple jobs.

Nachfolgend ein Beispiel für die Syntax in jedem System:

script:
artifacts:
  paths:
    - math-homework.txt

- name: Upload math result for job 1
  uses: actions/upload-artifact@v2
  with:
    name: homework
    path: math-homework.txt

For more information, see "Storing workflow data as artifacts."

Databases and service containers

Mit beiden Systemen kannst Du zusätzliche Container für Datenbanken, Zwischenspeicherung im Cache oder andere Abhängigkeiten einbinden.

In GitLab CI/CD, a container for the job is specified with the image key, while GitHub Actions uses the container key. In both systems, additional service containers are specified with the services key.

Nachfolgend ein Beispiel für die Syntax in jedem System:

container-job:
  variables:
    POSTGRES_PASSWORD: postgres
    # The hostname used to communicate with the
    # PostgreSQL service container
    POSTGRES_HOST: postgres
    # The default PostgreSQL port
    POSTGRES_PORT: 5432
  image: node:10.18-jessie
  services:
    - postgres
  script:
    # Performs a clean installation of all dependencies
    # in the `package.json` file
    - npm ci
    # Runs a script that creates a PostgreSQL client,
    # populates the client with data, and retrieves data
    - node client.js
  tags:
    - docker

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie

    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres

    steps:
      - name: Check out repository code
        uses: actions/checkout@v2

      # Performs a clean installation of all dependencies
      # in the `package.json` file
      - name: Install dependencies
        run: npm ci

      - name: Connect to PostgreSQL
        # Runs a script that creates a PostgreSQL client,
        # populates the client with data, and retrieves data
        run: node client.js
        env:
          # The hostname used to communicate with the
          # PostgreSQL service container
          POSTGRES_HOST: postgres
          # The default PostgreSQL port
          POSTGRES_PORT: 5432

For more information, see "About service containers."