diff --git a/content/actions/learn-github-actions/index.md b/content/actions/learn-github-actions/index.md index 9329c5bac2e2..8bc97d038f8e 100644 --- a/content/actions/learn-github-actions/index.md +++ b/content/actions/learn-github-actions/index.md @@ -37,5 +37,6 @@ versions: {% link_with_intro /sharing-workflows-with-your-organization %} {% link_with_intro /security-hardening-for-github-actions %} {% link_with_intro /migrating-from-circleci-to-github-actions %} +{% link_with_intro /migrating-from-gitlab-cicd-to-github-actions %} {% link_with_intro /migrating-from-azure-pipelines-to-github-actions %} {% link_with_intro /migrating-from-jenkins-to-github-actions %} diff --git a/content/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions.md b/content/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions.md new file mode 100644 index 000000000000..873144e8fe04 --- /dev/null +++ b/content/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions.md @@ -0,0 +1,476 @@ +--- +title: Migrating from GitLab CI/CD to GitHub Actions +intro: '{% data variables.product.prodname_actions %} and GitLab CI/CD share several configuration similarities, which makes migrating to {% data variables.product.prodname_actions %} relatively straightforward.' +versions: + free-pro-team: '*' + enterprise-server: '>=2.22' +--- + +{% data reusables.actions.enterprise-beta %} +{% data reusables.actions.enterprise-github-hosted-runners %} + +### Introduction + +GitLab CI/CD and {% data variables.product.prodname_actions %} both allow you to create workflows that automatically build, test, publish, release, and deploy code. GitLab CI/CD and {% data variables.product.prodname_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 {% data variables.product.prodname_actions %}. + +### Jobs + +Jobs in GitLab CI/CD are very similar to jobs in {% data variables.product.prodname_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 {% data variables.product.prodname_actions %}, all scripts are specified using the `run` key. + +Below is an example of the syntax for each system: + + + + + + + + + + +
+GitLab CI/CD + +{% data variables.product.prodname_actions %} +
+{% raw %} +```yaml +job1: + variables: + GIT_CHECKOUT: "true" + script: + - echo "Run your script here" +``` +{% endraw %} + +{% raw %} +```yaml +jobs: + job1: + steps: + - uses: actions/checkout@v2 + - run: echo "Run your script here" +``` +{% endraw %} +
+ +### Runners + +Runners are machines on which the jobs run. Both GitLab CI/CD and {% data variables.product.prodname_actions %} offer managed and self-hosted variants of runners. In GitLab CI/CD, `tags` are used to run jobs on different platforms, while in {% data variables.product.prodname_actions %} it is done with the `runs-on` key. + +Below is an example of the syntax for each system: + + + + + + + + + + +
+GitLab CI/CD + +{% data variables.product.prodname_actions %} +
+{% raw %} +```yaml +windows_job: + tags: + - windows + script: + - echo Hello, %USERNAME%! + +linux_job: + tags: + - linux + script: + - echo "Hello, $USER!" +``` +{% endraw %} + +{% raw %} +```yaml +windows_job: + runs-on : windows-latest + steps: + - run: echo Hello, %USERNAME%! + +linux_job: + runs-on: ubuntu-latest + steps: + - run: echo "Hello, $USER!" +``` +{% endraw %} +
+ +For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)." + +### Docker images + +Both GitLab CI/CD and {% data variables.product.prodname_actions %} support running jobs in a Docker image. In GitLab CI/CD, Docker images are defined with a `image` key, while in {% data variables.product.prodname_actions %} it is done with the `container` key. + +Below is an example of the syntax for each system: + + + + + + + + + + +
+GitLab CI/CD + +{% data variables.product.prodname_actions %} +
+{% raw %} +```yaml +my_job: + image: node:10.16-jessie +``` +{% endraw %} + +{% raw %} +```yaml +jobs: + my_job: + container: node:10.16-jessie +``` +{% endraw %} +
+ +For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer)." + +### Condition and expression syntax + +GitLab CI/CD uses `rules` to determine if a job will run for a specific condition. {% data variables.product.prodname_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: + + + + + + + + + + +
+GitLab CI/CD + +{% data variables.product.prodname_actions %} +
+{% raw %} +```yaml +deploy_prod: + stage: deploy + script: + - echo "Deply to production server" + rules: + - if: '$CI_COMMIT_BRANCH == "master"' +``` +{% endraw %} + +{% raw %} +```yaml +jobs: + deploy_prod: + if: contains( github.ref, 'master') + runs-on: ubuntu-latest + steps: + - run: echo "Deply to production server" +``` +{% endraw %} +
+ +For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)." + +### Dependencies between Jobs + +Both GitLab CI/CD and {% data variables.product.prodname_actions %} allow you to set dependencies for a job. In both systems, jobs run in parallel by default, but job dependencies in {% data variables.product.prodname_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 {% data variables.product.prodname_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. + + + + + + + + + + +
+GitLab CI/CD + +{% data variables.product.prodname_actions %} +
+{% raw %} +```yaml +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" +``` +{% endraw %} + +{% raw %} +```yaml +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" +``` +{% endraw %} +
+ +For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)." + +### Scheduling workflows + +Both GitLab CI/CD and {% data variables.product.prodname_actions %} allow you to run workflows at a specific interval. In GitLab CI/CD, pipeline schedules are configured with the UI, while in {% data variables.product.prodname_actions %} you can trigger a workflow on a scheduled interval with the "on" key. + +For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows#scheduled-events)." + +### Variables and secrets + +GitLab CI/CD and {% data variables.product.prodname_actions %} support setting environment variables in the pipeline or workflow configuration file, and creating secrets using the GitLab or {% data variables.product.product_name %} UI. + +For more information, see "[Environment variables](/actions/reference/environment-variables)" and "[Encrypted secrets](/actions/reference/encrypted-secrets)." + +### Caching + +GitLab CI/CD and {% data variables.product.prodname_actions %} provide a method in the configuration file to manually cache workflow files. + +Below is an example of the syntax for each system: + + + + + + + + + + +
+GitLab CI/CD + +{% data variables.product.prodname_actions %} +
+{% raw %} +```yaml +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 +``` +{% endraw %} + +{% raw %} +```yaml +jobs: + test_async: + - name: Cache node modules + uses: actions/cache@v2 + with: + path: ~/.npm + key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }} + restore-keys: v1-npm-deps- +``` +{% endraw %} +
+ +For more information, see "[Caching dependencies to speed up workflows](/actions/guides/caching-dependencies-to-speed-up-workflows)." + +### Artifacts + +Both GitLab CI/CD and {% data variables.product.prodname_actions %} can upload files and directories created by a job as artifacts. In {% data variables.product.prodname_actions %}, artifacts can be used to persist data across multiple jobs. + +Below is an example of the syntax for each system: + + + + + + + + + + +
+GitLab CI/CD + +{% data variables.product.prodname_actions %} +
+{% raw %} +```yaml +script: +artifacts: + paths: + - math-homework.txt +``` +{% endraw %} + +{% raw %} +```yaml +- name: Upload math result for job 1 + uses: actions/upload-artifact@v2 + with: + name: homework + path: math-homework.txt +``` +{% endraw %} +
+ +For more information, see "[Storing workflow data as artifacts](/actions/guides/storing-workflow-data-as-artifacts)." + +### Databases and service containers + +Both systems enable you to include additional containers for databases, caching, or other dependencies. + +In GitLab CI/CD, a container for the job is specified with the `image` key, while {% data variables.product.prodname_actions %} uses the `container` key. In both systems, additional service containers are specified with the `services` key. + +Below is an example of the syntax for each system: + + + + + + + + + + +
+GitLab CI/CD + +{% data variables.product.prodname_actions %} +
+{% raw %} +```yaml +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 +``` +{% endraw %} + +{% raw %} +```yaml +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 +``` +{% endraw %} +
+ +For more information, see "[About service containers](/actions/guides/about-service-containers)." diff --git a/content/index.md b/content/index.md index ba3d56935da4..1800e3661d03 100644 --- a/content/index.md +++ b/content/index.md @@ -13,3 +13,4 @@ popularLinks: - /github/working-with-github-pages versions: '*' --- +