From 729fc74a2c810f7b9c8593d4f45096d705b00172 Mon Sep 17 00:00:00 2001 From: Ahmed Bilal Date: Sat, 12 Sep 2020 00:07:59 -0700 Subject: [PATCH 1/5] Adding gitlab migration guide --- .../migrating-to-github-actions/index.md | 15 + ...migrating-from-gitlab-to-github-actions.md | 471 ++++++++++++++++++ 2 files changed, 486 insertions(+) create mode 100644 content/actions/migrating-to-github-actions/index.md create mode 100644 content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md diff --git a/content/actions/migrating-to-github-actions/index.md b/content/actions/migrating-to-github-actions/index.md new file mode 100644 index 000000000000..09aaf2a9b980 --- /dev/null +++ b/content/actions/migrating-to-github-actions/index.md @@ -0,0 +1,15 @@ +--- +title: Migrating to GitHub Actions +intro: 'Migrate from other continuous integration (CI) providers to {{ site.data.variables.product.prodname_actions }}.' +productVersions: + actions: '*' + enterprise: '>=2.22' +--- + +{{ site.data.reusables.actions.enterprise-beta }} +{{ site.data.reusables.actions.enterprise-github-hosted-runners }} + +{% link_in_list /migrating-from-circleci-to-github-actions %} +{% link_in_list /migrating-from-gitlab-to-github-actions %} +{% link_in_list /migrating-from-azure-pipelines-to-github-actions %} +{% link_in_list /migrating-from-jenkins-to-github-actions %} \ No newline at end of file diff --git a/content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md b/content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md new file mode 100644 index 000000000000..b2fd29f3ceee --- /dev/null +++ b/content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md @@ -0,0 +1,471 @@ +--- +title: Migrating from GitLab to GitHub Actions +intro: '{{ site.data.variables.product.prodname_actions }} and GitLab share several configuration similarities, which makes migrating to {{ site.data.variables.product.prodname_actions }} relatively straightforward.' +productVersions: + dotcom: '*' + enterprise: '>=2.22' +--- + +{{ site.data.reusables.actions.enterprise-beta }} +{{ site.data.reusables.actions.enterprise-github-hosted-runners }} + +### Introduction + +GitLab and {{ site.data.variables.product.prodname_actions }} both allow you to create workflows that automatically build, test, publish, release, and deploy code. GitLab and {{ site.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 both managed or on self-hosted machines. + +There are a few differences, and this article will guide you to important differences so that you can easily migrate your workflow to GitHub Actions. + +### Jobs + +Jobs in GitLab are very similar to jobs in {{ site.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 run on separate virtual machines or in separate containers. [ need to check] +* 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, script steps are specified using the `script` key. In {{ site.data.variables.product.prodname_actions }}, all scripts are specified using the `run` key. + +Below is an example of the syntax for each system: + + + + + + + + + + +
+GitLab + +{{ site.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 and {{ site.data.variables.product.prodname_actions }} offers managed and self-hosted variants of runners. In GitLab, `tags` are used to run jobs on different platforms while the same is done in {{ site.data.variables.product.prodname_actions }} with a `runs-on` key. + +Below is an example of the syntax for each system. + + + + + + + + + + +
+GitLab + +GitHub 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 %} +
+ +### Docker Images + +Both GitLab and {{ site.data.variables.product.prodname_actions }} support running steps inside of a Docker image. In GitLab, docker images are defined with a `image` key while in GitHub Actions, the same can be done with a `container` key. + +Below is an example of the syntax for each system: + + + + + + + + + + +
+GitLab + +{{ site.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 "[Syntax for Containers](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer)." + +### Conditionals and Expression syntax + +GitLab uses `rules` to determine if the job will or will not run for a specific condition. GitHub Actions provide a `if` keyword to prevent a job from running unless a condition is met. + +Below is an example of the syntax for each system: + + + + + + + + + + +
+GitLab + +{{ site.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' ) + steps: + - run: echo "Deply to production server" +``` +{% endraw %} +
+ +For more information, see "[Context and expression syntax for {{ site.data.variables.product.prodname_actions }}](/actions/reference/context-and-expression-syntax-for-github-actions)." + +### Dependencies between Jobs + +Both GitLab and {{ site.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 can be specified explicitly with the `needs` key. GitLab also has a concept of `stages`, where jobs in a stage run concurrently, but the next stage will kick in once all the jobs in the previous stage has completed. You can easily recreate this scenario in GitHub Actions with the `needs` keys. + +Below is an example of the syntax for each system. The workflows start with two jobs named `build_a` and `build_b`, and when these jobs complete, another job called `test_ab` will run. Finally, when this job complete, the job `deploy` will run. + + + + + + + + + + +
+GitLab + +{{ site.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 buil_b have finished." + +deploy_ab: + stage: test + 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 buil_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 %} +
+ +### Scheduled Jobs + +Both GitLab and {{ site.data.variables.product.prodname_actions }} allow you to run workflows at a specific interval. In GitLab, pipeline schedules are configured with a UI, while in GitHub Actions, you can trigger a workflow on the scheduled interval with the "on" key. + +For more information, see "[Scheduled events](/actions/reference/events-that-trigger-workflows#scheduled-events)." + +### Variables and Secrets + +GitLab and {{ site.data.variables.product.prodname_actions }} support setting environment variables in the configuration file and creating secrets using the GitLab or {{ site.data.variables.product.product_name }} UI. + +For more information, see "[Using environment variables](/actions/configuring-and-managing-workflows/using-environment-variables)" and "[Creating and using encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)." + +### Caching + +GitLab and {{ site.data.variables.product.prodname_actions }} provide a method to manually cache files in the configuration file. + +Below is an example of the syntax for each system. + + + + + + + + + + +
+GitLab + +GitHub 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/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows)." + +### Artifacts + +Both GitLab and {{ site.data.variables.product.prodname_actions }} provide `artifacts` to upload files and directories created by the job. In {{ site.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 + +GitHub 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 "[Persisting workflow data using artifacts](/actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts)." + +### Databases and Service containers + +Both systems enable you to include additional containers for databases, caching, or other dependencies. + +In GitLab, primary containers are specified with a `image` key while {{ site.data.variables.product.prodname_actions }} use `container` key for primary containers. In both system additional containers can be specificed with `services` key. + +Below is an example in GitLab and {{ site.data.variables.product.prodname_actions }} configuration syntax. + + + + + + + + + + +
+GitLab + +GitHub 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/configuring-and-managing-workflows/about-service-containers)." \ No newline at end of file From a03a8f162c46f097c4a821a34e7355175607c1be Mon Sep 17 00:00:00 2001 From: Rachael Sewell Date: Mon, 5 Oct 2020 13:45:08 -0700 Subject: [PATCH 2/5] update to latest versioning syntax --- content/actions/migrating-to-github-actions/index.md | 8 ++++---- .../migrating-from-gitlab-to-github-actions.md | 8 ++++---- content/index.md | 1 + 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/content/actions/migrating-to-github-actions/index.md b/content/actions/migrating-to-github-actions/index.md index 09aaf2a9b980..630a7304eb58 100644 --- a/content/actions/migrating-to-github-actions/index.md +++ b/content/actions/migrating-to-github-actions/index.md @@ -1,9 +1,9 @@ --- title: Migrating to GitHub Actions intro: 'Migrate from other continuous integration (CI) providers to {{ site.data.variables.product.prodname_actions }}.' -productVersions: - actions: '*' - enterprise: '>=2.22' +versions: + free-pro-team: '*' + enterprise-server: '>=2.22' --- {{ site.data.reusables.actions.enterprise-beta }} @@ -12,4 +12,4 @@ productVersions: {% link_in_list /migrating-from-circleci-to-github-actions %} {% link_in_list /migrating-from-gitlab-to-github-actions %} {% link_in_list /migrating-from-azure-pipelines-to-github-actions %} -{% link_in_list /migrating-from-jenkins-to-github-actions %} \ No newline at end of file +{% link_in_list /migrating-from-jenkins-to-github-actions %} diff --git a/content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md b/content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md index b2fd29f3ceee..b87f8deb2ecd 100644 --- a/content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md +++ b/content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md @@ -1,9 +1,9 @@ --- title: Migrating from GitLab to GitHub Actions intro: '{{ site.data.variables.product.prodname_actions }} and GitLab share several configuration similarities, which makes migrating to {{ site.data.variables.product.prodname_actions }} relatively straightforward.' -productVersions: - dotcom: '*' - enterprise: '>=2.22' +versions: + free-pro-team: '*' + enterprise-server: '>=2.22' --- {{ site.data.reusables.actions.enterprise-beta }} @@ -468,4 +468,4 @@ jobs: -For more information, see "[About service containers](/actions/configuring-and-managing-workflows/about-service-containers)." \ No newline at end of file +For more information, see "[About service containers](/actions/configuring-and-managing-workflows/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: '*' --- + From 0cff52c79ec245ca2f75649648dbcd6bfd601be0 Mon Sep 17 00:00:00 2001 From: Rachael Sewell Date: Mon, 5 Oct 2020 13:47:12 -0700 Subject: [PATCH 3/5] update to latest reusable syntax --- .../migrating-to-github-actions/index.md | 6 +-- ...migrating-from-gitlab-to-github-actions.md | 40 +++++++++---------- 2 files changed, 23 insertions(+), 23 deletions(-) diff --git a/content/actions/migrating-to-github-actions/index.md b/content/actions/migrating-to-github-actions/index.md index 630a7304eb58..cec3236f207e 100644 --- a/content/actions/migrating-to-github-actions/index.md +++ b/content/actions/migrating-to-github-actions/index.md @@ -1,13 +1,13 @@ --- title: Migrating to GitHub Actions -intro: 'Migrate from other continuous integration (CI) providers to {{ site.data.variables.product.prodname_actions }}.' +intro: 'Migrate from other continuous integration (CI) providers to {% data variables.product.prodname_actions %}.' versions: free-pro-team: '*' enterprise-server: '>=2.22' --- -{{ site.data.reusables.actions.enterprise-beta }} -{{ site.data.reusables.actions.enterprise-github-hosted-runners }} +{% data reusables.actions.enterprise-beta %} +{% data reusables.actions.enterprise-github-hosted-runners %} {% link_in_list /migrating-from-circleci-to-github-actions %} {% link_in_list /migrating-from-gitlab-to-github-actions %} diff --git a/content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md b/content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md index b87f8deb2ecd..5c5afd521bcf 100644 --- a/content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md +++ b/content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md @@ -1,17 +1,17 @@ --- title: Migrating from GitLab to GitHub Actions -intro: '{{ site.data.variables.product.prodname_actions }} and GitLab share several configuration similarities, which makes migrating to {{ site.data.variables.product.prodname_actions }} relatively straightforward.' +intro: '{% data variables.product.prodname_actions %} and GitLab share several configuration similarities, which makes migrating to {% data variables.product.prodname_actions %} relatively straightforward.' versions: free-pro-team: '*' enterprise-server: '>=2.22' --- -{{ site.data.reusables.actions.enterprise-beta }} -{{ site.data.reusables.actions.enterprise-github-hosted-runners }} +{% data reusables.actions.enterprise-beta %} +{% data reusables.actions.enterprise-github-hosted-runners %} ### Introduction -GitLab and {{ site.data.variables.product.prodname_actions }} both allow you to create workflows that automatically build, test, publish, release, and deploy code. GitLab and {{ site.data.variables.product.prodname_actions }} share some similarities in workflow configuration: +GitLab and {% data variables.product.prodname_actions %} both allow you to create workflows that automatically build, test, publish, release, and deploy code. GitLab 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. @@ -22,13 +22,13 @@ There are a few differences, and this article will guide you to important differ ### Jobs -Jobs in GitLab are very similar to jobs in {{ site.data.variables.product.prodname_actions }}. In both systems, jobs have the following characteristics: +Jobs in GitLab 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 run on separate virtual machines or in separate containers. [ need to check] * 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, script steps are specified using the `script` key. In {{ site.data.variables.product.prodname_actions }}, all scripts are specified using the `run` key. +You can run a script or a shell command in a job. In GitLab, 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: @@ -38,7 +38,7 @@ Below is an example of the syntax for each system: GitLab -{{ site.data.variables.product.prodname_actions }} +{% data variables.product.prodname_actions %} @@ -69,7 +69,7 @@ jobs: ### Runners -Runners are machines on which the jobs run. Both GitLab and {{ site.data.variables.product.prodname_actions }} offers managed and self-hosted variants of runners. In GitLab, `tags` are used to run jobs on different platforms while the same is done in {{ site.data.variables.product.prodname_actions }} with a `runs-on` key. +Runners are machines on which the jobs run. Both GitLab and {% data variables.product.prodname_actions %} offers managed and self-hosted variants of runners. In GitLab, `tags` are used to run jobs on different platforms while the same is done in {% data variables.product.prodname_actions %} with a `runs-on` key. Below is an example of the syntax for each system. @@ -120,7 +120,7 @@ linux_job: ### Docker Images -Both GitLab and {{ site.data.variables.product.prodname_actions }} support running steps inside of a Docker image. In GitLab, docker images are defined with a `image` key while in GitHub Actions, the same can be done with a `container` key. +Both GitLab and {% data variables.product.prodname_actions %} support running steps inside of a Docker image. In GitLab, docker images are defined with a `image` key while in GitHub Actions, the same can be done with a `container` key. Below is an example of the syntax for each system: @@ -130,7 +130,7 @@ Below is an example of the syntax for each system: GitLab -{{ site.data.variables.product.prodname_actions }} +{% data variables.product.prodname_actions %} @@ -168,7 +168,7 @@ Below is an example of the syntax for each system: GitLab -{{ site.data.variables.product.prodname_actions }} +{% data variables.product.prodname_actions %} @@ -198,11 +198,11 @@ jobs: -For more information, see "[Context and expression syntax for {{ site.data.variables.product.prodname_actions }}](/actions/reference/context-and-expression-syntax-for-github-actions)." +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 and {{ site.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 can be specified explicitly with the `needs` key. GitLab also has a concept of `stages`, where jobs in a stage run concurrently, but the next stage will kick in once all the jobs in the previous stage has completed. You can easily recreate this scenario in GitHub Actions with the `needs` keys. +Both GitLab 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 can be specified explicitly with the `needs` key. GitLab also has a concept of `stages`, where jobs in a stage run concurrently, but the next stage will kick in once all the jobs in the previous stage has completed. You can easily recreate this scenario in GitHub Actions with the `needs` keys. Below is an example of the syntax for each system. The workflows start with two jobs named `build_a` and `build_b`, and when these jobs complete, another job called `test_ab` will run. Finally, when this job complete, the job `deploy` will run. @@ -212,7 +212,7 @@ Below is an example of the syntax for each system. The workflows start with two GitLab -{{ site.data.variables.product.prodname_actions }} +{% data variables.product.prodname_actions %} @@ -279,19 +279,19 @@ jobs: ### Scheduled Jobs -Both GitLab and {{ site.data.variables.product.prodname_actions }} allow you to run workflows at a specific interval. In GitLab, pipeline schedules are configured with a UI, while in GitHub Actions, you can trigger a workflow on the scheduled interval with the "on" key. +Both GitLab and {% data variables.product.prodname_actions %} allow you to run workflows at a specific interval. In GitLab, pipeline schedules are configured with a UI, while in GitHub Actions, you can trigger a workflow on the scheduled interval with the "on" key. For more information, see "[Scheduled events](/actions/reference/events-that-trigger-workflows#scheduled-events)." ### Variables and Secrets -GitLab and {{ site.data.variables.product.prodname_actions }} support setting environment variables in the configuration file and creating secrets using the GitLab or {{ site.data.variables.product.product_name }} UI. +GitLab and {% data variables.product.prodname_actions %} support setting environment variables in the configuration file and creating secrets using the GitLab or {% data variables.product.product_name %} UI. For more information, see "[Using environment variables](/actions/configuring-and-managing-workflows/using-environment-variables)" and "[Creating and using encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)." ### Caching -GitLab and {{ site.data.variables.product.prodname_actions }} provide a method to manually cache files in the configuration file. +GitLab and {% data variables.product.prodname_actions %} provide a method to manually cache files in the configuration file. Below is an example of the syntax for each system. @@ -345,7 +345,7 @@ For more information, see "[Caching dependencies to speed up workflows](/actions ### Artifacts -Both GitLab and {{ site.data.variables.product.prodname_actions }} provide `artifacts` to upload files and directories created by the job. In {{ site.data.variables.product.prodname_actions }}, artifacts can be used to persist data across multiple jobs. +Both GitLab and {% data variables.product.prodname_actions %} provide `artifacts` to upload files and directories created by the job. 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. @@ -389,9 +389,9 @@ For more information, see "[Persisting workflow data using artifacts](/actions/c Both systems enable you to include additional containers for databases, caching, or other dependencies. -In GitLab, primary containers are specified with a `image` key while {{ site.data.variables.product.prodname_actions }} use `container` key for primary containers. In both system additional containers can be specificed with `services` key. +In GitLab, primary containers are specified with a `image` key while {% data variables.product.prodname_actions %} use `container` key for primary containers. In both system additional containers can be specificed with `services` key. -Below is an example in GitLab and {{ site.data.variables.product.prodname_actions }} configuration syntax. +Below is an example in GitLab and {% data variables.product.prodname_actions %} configuration syntax. From f29279f7fbc40644c61ce4dc0d37f6be3acd88f3 Mon Sep 17 00:00:00 2001 From: Rachael Sewell Date: Mon, 5 Oct 2020 13:55:50 -0700 Subject: [PATCH 4/5] restructure guide to new location --- content/actions/learn-github-actions/index.md | 1 + .../migrating-from-gitlab-to-github-actions.md | 0 .../actions/migrating-to-github-actions/index.md | 15 --------------- 3 files changed, 1 insertion(+), 15 deletions(-) rename content/actions/{migrating-to-github-actions => learn-github-actions}/migrating-from-gitlab-to-github-actions.md (100%) delete mode 100644 content/actions/migrating-to-github-actions/index.md diff --git a/content/actions/learn-github-actions/index.md b/content/actions/learn-github-actions/index.md index 9329c5bac2e2..79b3d9234de2 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-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/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md b/content/actions/learn-github-actions/migrating-from-gitlab-to-github-actions.md similarity index 100% rename from content/actions/migrating-to-github-actions/migrating-from-gitlab-to-github-actions.md rename to content/actions/learn-github-actions/migrating-from-gitlab-to-github-actions.md diff --git a/content/actions/migrating-to-github-actions/index.md b/content/actions/migrating-to-github-actions/index.md deleted file mode 100644 index cec3236f207e..000000000000 --- a/content/actions/migrating-to-github-actions/index.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Migrating to GitHub Actions -intro: 'Migrate from other continuous integration (CI) providers to {% data variables.product.prodname_actions %}.' -versions: - free-pro-team: '*' - enterprise-server: '>=2.22' ---- - -{% data reusables.actions.enterprise-beta %} -{% data reusables.actions.enterprise-github-hosted-runners %} - -{% link_in_list /migrating-from-circleci-to-github-actions %} -{% link_in_list /migrating-from-gitlab-to-github-actions %} -{% link_in_list /migrating-from-azure-pipelines-to-github-actions %} -{% link_in_list /migrating-from-jenkins-to-github-actions %} From 851d90dc528ce58408f9e12e17ac86adca0dfe61 Mon Sep 17 00:00:00 2001 From: Lucas Costi Date: Wed, 7 Oct 2020 14:29:32 +1000 Subject: [PATCH 5/5] GitLab migration guide edit --- content/actions/learn-github-actions/index.md | 2 +- ...ing-from-gitlab-cicd-to-github-actions.md} | 109 +++++++++--------- 2 files changed, 58 insertions(+), 53 deletions(-) rename content/actions/learn-github-actions/{migrating-from-gitlab-to-github-actions.md => migrating-from-gitlab-cicd-to-github-actions.md} (53%) diff --git a/content/actions/learn-github-actions/index.md b/content/actions/learn-github-actions/index.md index 79b3d9234de2..8bc97d038f8e 100644 --- a/content/actions/learn-github-actions/index.md +++ b/content/actions/learn-github-actions/index.md @@ -37,6 +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-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-to-github-actions.md b/content/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions.md similarity index 53% rename from content/actions/learn-github-actions/migrating-from-gitlab-to-github-actions.md rename to content/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions.md index 5c5afd521bcf..873144e8fe04 100644 --- a/content/actions/learn-github-actions/migrating-from-gitlab-to-github-actions.md +++ b/content/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions.md @@ -1,6 +1,6 @@ --- -title: Migrating from GitLab to GitHub Actions -intro: '{% data variables.product.prodname_actions %} and GitLab share several configuration similarities, which makes migrating to {% data variables.product.prodname_actions %} relatively straightforward.' +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' @@ -11,31 +11,31 @@ versions: ### Introduction -GitLab and {% data variables.product.prodname_actions %} both allow you to create workflows that automatically build, test, publish, release, and deploy code. GitLab and {% data variables.product.prodname_actions %} share some similarities in workflow configuration: +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 both managed or on self-hosted machines. +- Jobs can run on either managed or self-hosted machines. -There are a few differences, and this article will guide you to important differences so that you can easily migrate your workflow to GitHub Actions. +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 are very similar to jobs in {% data variables.product.prodname_actions %}. In both systems, jobs have the following characteristics: +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 run on separate virtual machines or in separate containers. [ need to check] +* 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, script steps are specified using the `script` key. In {% data variables.product.prodname_actions %}, all scripts are specified using the `run` key. +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 +GitLab CI/CD {% data variables.product.prodname_actions %} @@ -48,7 +48,7 @@ GitLab job1: variables: GIT_CHECKOUT: "true" - script: + script: - echo "Run your script here" ``` {% endraw %} @@ -69,17 +69,17 @@ jobs: ### Runners -Runners are machines on which the jobs run. Both GitLab and {% data variables.product.prodname_actions %} offers managed and self-hosted variants of runners. In GitLab, `tags` are used to run jobs on different platforms while the same is done in {% data variables.product.prodname_actions %} with a `runs-on` key. +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. +Below is an example of the syntax for each system: @@ -118,16 +118,18 @@ linux_job:
-GitLab +GitLab CI/CD -GitHub Actions +{% data variables.product.prodname_actions %}
-### Docker Images +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 and {% data variables.product.prodname_actions %} support running steps inside of a Docker image. In GitLab, docker images are defined with a `image` key while in GitHub Actions, the same can be done with a `container` key. +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 +GitLab CI/CD {% data variables.product.prodname_actions %} @@ -154,18 +156,18 @@ jobs:
-For more information, see "[Syntax for Containers](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer)." +For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer)." -### Conditionals and Expression syntax +### Condition and expression syntax -GitLab uses `rules` to determine if the job will or will not run for a specific condition. GitHub Actions provide a `if` keyword to prevent a job from running unless a condition is met. +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 +GitLab CI/CD {% data variables.product.prodname_actions %} @@ -189,9 +191,10 @@ deploy_prod: ```yaml jobs: deploy_prod: - if: contains( github.ref, 'master' ) + if: contains( github.ref, 'master') + runs-on: ubuntu-latest steps: - - run: echo "Deply to production server" + - run: echo "Deply to production server" ``` {% endraw %} @@ -202,14 +205,14 @@ For more information, see "[Context and expression syntax for {% data variables. ### Dependencies between Jobs -Both GitLab 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 can be specified explicitly with the `needs` key. GitLab also has a concept of `stages`, where jobs in a stage run concurrently, but the next stage will kick in once all the jobs in the previous stage has completed. You can easily recreate this scenario in GitHub Actions with the `needs` keys. +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`, and when these jobs complete, another job called `test_ab` will run. Finally, when this job complete, the job `deploy` will run. +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 +GitLab CI/CD {% data variables.product.prodname_actions %} @@ -237,10 +240,10 @@ build_b: test_ab: stage: test script: - - echo "This job will run after build_a and buil_b have finished." + - echo "This job will run after build_a and build_b have finished." deploy_ab: - stage: test + stage: deploy script: - echo "This job will run after test_ab is complete" ``` @@ -264,44 +267,46 @@ jobs: runs-on: ubuntu-latest needs: [build_a,build_b] steps: - - run: echo "This job will run after build_a and buil_b have finished" + - 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" + - run: echo "This job will run after test_ab is complete" ``` {% endraw %}
-### Scheduled Jobs +For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)." -Both GitLab and {% data variables.product.prodname_actions %} allow you to run workflows at a specific interval. In GitLab, pipeline schedules are configured with a UI, while in GitHub Actions, you can trigger a workflow on the scheduled interval with the "on" key. +### Scheduling workflows -For more information, see "[Scheduled events](/actions/reference/events-that-trigger-workflows#scheduled-events)." +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. -### Variables and Secrets +For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows#scheduled-events)." -GitLab and {% data variables.product.prodname_actions %} support setting environment variables in the configuration file and creating secrets using the GitLab or {% data variables.product.product_name %} UI. +### Variables and secrets -For more information, see "[Using environment variables](/actions/configuring-and-managing-workflows/using-environment-variables)" and "[Creating and using encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-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 and {% data variables.product.prodname_actions %} provide a method to manually cache files in the configuration file. +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. +Below is an example of the syntax for each system: @@ -341,21 +346,21 @@ jobs:
-GitLab +GitLab CI/CD -GitHub Actions +{% data variables.product.prodname_actions %}
-For more information, see "[Caching dependencies to speed up workflows](/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows)." +For more information, see "[Caching dependencies to speed up workflows](/actions/guides/caching-dependencies-to-speed-up-workflows)." ### Artifacts -Both GitLab and {% data variables.product.prodname_actions %} provide `artifacts` to upload files and directories created by the job. In {% data variables.product.prodname_actions %}, artifacts can be used to persist data across multiple jobs. +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. +Below is an example of the syntax for each system: @@ -383,23 +388,23 @@ artifacts:
-GitLab +GitLab CI/CD -GitHub Actions +{% data variables.product.prodname_actions %}
-For more information, see "[Persisting workflow data using artifacts](/actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts)." +For more information, see "[Storing workflow data as artifacts](/actions/guides/storing-workflow-data-as-artifacts)." -### Databases and Service containers +### Databases and service containers Both systems enable you to include additional containers for databases, caching, or other dependencies. -In GitLab, primary containers are specified with a `image` key while {% data variables.product.prodname_actions %} use `container` key for primary containers. In both system additional containers can be specificed with `services` key. +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 in GitLab and {% data variables.product.prodname_actions %} configuration syntax. +Below is an example of the syntax for each system: @@ -468,4 +473,4 @@ jobs:
-GitLab +GitLab CI/CD -GitHub Actions +{% data variables.product.prodname_actions %}
-For more information, see "[About service containers](/actions/configuring-and-managing-workflows/about-service-containers)." +For more information, see "[About service containers](/actions/guides/about-service-containers)."