Migrating from GitLab CI/CD to GitHub Actions

Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.

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.

GitLab CI/CD syntax for jobs

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

GitHub Actions syntax for jobs

jobs:
  job1:
    steps:
      - uses: {% data reusables.actions.action-checkout %}
      - 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.