{"meta":{"title":"GitLab CI/CD から GitHub Actions への移行","intro":"GitHub Actions と GitLab CI/CDはいくつかの点で設定が似ているため、GitHub Actions への移行は比較的簡単です。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/actions","title":"GitHub Actions"},{"href":"/ja/actions/tutorials","title":"チュートリアル"},{"href":"/ja/actions/tutorials/migrate-to-github-actions","title":"GitHub Actions に移行する"},{"href":"/ja/actions/tutorials/migrate-to-github-actions/manual-migrations","title":"手動移行"},{"href":"/ja/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-gitlab-cicd","title":"GitLab CI/CD から移行する"}],"documentType":"article"},"body":"# GitLab CI/CD から GitHub Actions への移行\n\nGitHub Actions と GitLab CI/CDはいくつかの点で設定が似ているため、GitHub Actions への移行は比較的簡単です。\n\n## はじめに\n\nGitLab CI/CD と GitHub Actions は、どちらも自動的にコードのビルド、テスト、公開、リリース、デプロイを行うワークフローを作成できます。 GitLab CI/CD と GitHub Actions は、ワークフローの設定において似ているところがあります。\n\n* ワークフローの設定ファイルはYAMLで書かれ、コードのリポジトリに保存されます。\n* ワークフローには1つ以上のジョブが含まれます。\n* ジョブには1つ以上のステップもしくは個別のコマンドが含まれます。\n* ジョブは、マネージドマシンまたはセルフホストマシンのいずれかで実行できます。\n\nいくつかの違いがありますので、このガイドでは、ワークフローを GitHub Actions に移行できるようにする際の重要な違いを説明します。\n\n## ジョブ\n\nGitLab CI/CD のジョブは、GitHub Actions のジョブと非常によく似ています。 どちらのシステムでも、ジョブは以下の特徴を持ちます。\n\n* ジョブには、順番に実行される一連のステップまたはスクリプトが含まれています。\n* ジョブは、個別のマシンまたは個別のコンテナで実行できます。\n* ジョブは、デフォルトでは並列に実行されますが、順次実行するように設定することもできます。\n\nジョブ内でスクリプトまたはシェルコマンドを実行できます。 GitLab CI/CD では、`script` キーを使ってスクリプトのステップを指定します。 GitHub Actions では、`run` キーを使ってすべてのスクリプトを指定します。\n\n以下は、それぞれのシステムにおける構文の例です。\n\n### ジョブの GitLab CI/CD 構文\n\n```yaml\njob1:\n  variables:\n    GIT_CHECKOUT: \"true\"\n  script:\n    - echo \"Run your script here\"\n```\n\n### ジョブの GitHub Actions 構文\n\n```yaml\njobs:\n  job1:\n    steps:\n      - uses: actions/checkout@v6\n      - run: echo \"Run your script here\"\n```\n\n## ランナー\n\nランナーは、ジョブが実行されるマシンです。 GitLab CI/CD と GitHub Actions はどちらも、マネージドおよびセルフホストのランナーのバリエーションを提供しています。 GitLab CI/CD では、異なるプラットフォームでジョブを実行するために `tags` を使いますが、GitHub Actions では `runs-on` を使います。\n\n以下は、それぞれのシステムにおける構文の例です。\n\n### ランナーの GitLab CI/CD 構文\n\n```yaml\nwindows_job:\n  tags:\n    - windows\n  script:\n    - echo Hello, %USERNAME%!\n\nlinux_job:\n  tags:\n    - linux\n  script:\n    - echo \"Hello, $USER!\"\n```\n\n### ランナーの GitHub Actions 構文\n\n```yaml\nwindows_job:\n  runs-on: windows-latest\n  steps:\n    - run: echo Hello, %USERNAME%!\n\nlinux_job:\n  runs-on: ubuntu-latest\n  steps:\n    - run: echo \"Hello, $USER!\"\n```\n\n詳しくは、「[GitHub Actions　のワークフロー構文](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on)」をご覧ください。\n\n## Docker イメージ\n\nGitLab CI/CD と GitHub Actions はどちらも、Docker イメージ内でのジョブの実行をサポートしています。 GitLab CI/CD では、`image` キーを使って Docker イメージを定義しますが、GitHub Actions では `container` キーで行います。\n\n以下は、それぞれのシステムにおける構文の例です。\n\n### Docker イメージの GitLab CI/CD 構文\n\n```yaml\nmy_job:\n  image: node:20-bookworm-slim\n```\n\n### Docker イメージの GitHub Actions 構文\n\n```yaml\njobs:\n  my_job:\n    container: node:20-bookworm-slim\n```\n\n詳しくは、「[GitHub Actions　のワークフロー構文](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer)」をご覧ください。\n\n## 条件と式の構文\n\nGitLab CI/CD では、特定の条件でジョブを実行するかどうかを決定するために `rules` を使います。 GitHub Actions では、条件が満たされない場合にジョブが実行されないようにするには、`if` キーワードを使います。\n\n以下は、それぞれのシステムにおける構文の例です。\n\n### 条件と式の GitLab CI/CD 構文\n\n```yaml\ndeploy_prod:\n  stage: deploy\n  script:\n    - echo \"Deploy to production server\"\n  rules:\n    - if: '$CI_COMMIT_BRANCH == \"master\"'\n```\n\n### 条件と式の GitHub Actions 構文\n\n```yaml\njobs:\n  deploy_prod:\n    if: contains( github.ref, 'master')\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"Deploy to production server\"\n```\n\n詳しくは、「[ワークフロー内とアクション内で式を評価する](/ja/actions/learn-github-actions/expressions)」をご覧ください。\n\n## ジョブ間の依存関係\n\nGitLab CI/CD と GitHub Actions の両方で、ジョブの依存関係を設定できます。 どちらのシステムでも、ジョブは既定で並列に実行されますが、GitHub Actions のジョブの依存関係は `needs` キーで明示的に指定できます。 GitLab CI/CD には、`stages` の概念もあります。ステージ内のジョブは同時に実行されますが、次のステージは、前のステージのすべてのジョブが完了した時点で開始されます。 GitHub Actions では、`needs` キーを使ってこのシナリオを作り直すことができます。\n\n以下は、それぞれのシステムにおける構文の例です。 ワークフローは並列に実行される `build_a` と `build_b` という名前の 2 つのジョブで開始し、それらのジョブが完了すると、`test_ab` という別のジョブが実行されます。 最後に、`test_ab` が完了すると、`deploy_ab` ジョブが実行されます。\n\n### ジョブ間の依存関係の GitLab CI/CD 構文\n\n```yaml\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_a:\n  stage: build\n  script:\n    - echo \"This job will run first.\"\n\nbuild_b:\n  stage: build\n  script:\n    - echo \"This job will run first, in parallel with build_a.\"\n\ntest_ab:\n  stage: test\n  script:\n    - echo \"This job will run after build_a and build_b have finished.\"\n\ndeploy_ab:\n  stage: deploy\n  script:\n    - echo \"This job will run after test_ab is complete\"\n```\n\n### ジョブ間の依存関係の GitHub Actions 構文\n\n```yaml\njobs:\n  build_a:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first.\"\n\n  build_b:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first, in parallel with build_a\"\n\n  test_ab:\n    runs-on: ubuntu-latest\n    needs: [build_a,build_b]\n    steps:\n      - run: echo \"This job will run after build_a and build_b have finished\"\n\n  deploy_ab:\n    runs-on: ubuntu-latest\n    needs: [test_ab]\n    steps:\n      - run: echo \"This job will run after test_ab is complete\"\n```\n\n詳しくは、「[GitHub Actions　のワークフロー構文](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds)」をご覧ください。\n\n## ワークフローのスケジューリング\n\nGitLab CI/CD と GitHub Actions の両方を使用すると、特定の間隔でワークフローを実行できます。 GitLab CI/CD では、パイプラインスケジュールは UI で設定されますが、GitHub Actions では、「on」キーを使用してスケジュールされた間隔でワークフローをトリガーできます。\n\n詳しくは、「[ワークフローをトリガーするイベント](/ja/actions/using-workflows/events-that-trigger-workflows#scheduled-events)」をご覧ください。\n\n## 変数とシークレット\n\nGitLab CI/CD と GitHub Actions では、パイプラインまたはワークフロー構成ファイルでの変数の設定と、GitLab または GitHub の UI を使ったシークレットの作成がサポートされています。\n\n詳細については、「[変数に情報を格納する](/ja/actions/learn-github-actions/variables)」および「[シークレット](/ja/actions/security-for-github-actions/security-guides/about-secrets)」を参照してください。\n\n## キャッシュ\n\nGitLab CI/CD と GitHub Actions では、設定ファイルにワークフローファイルを手動でキャッシュするためのメソッドがあります。\n\n以下は、それぞれのシステムにおける構文の例です。\n\n### キャッシュの GitLab CI/CD 構文\n\n```yaml\nimage: node:latest\n\ncache:\n  key: $CI_COMMIT_REF_SLUG\n  paths:\n    - .npm/\n\nbefore_script:\n  - npm ci --cache .npm --prefer-offline\n\ntest_async:\n  script:\n    - node ./specs/start.js ./specs/async.spec.js\n```\n\n### キャッシュの GitHub Actions 構文\n\n```yaml\njobs:\n  test_async:\n    runs-on: ubuntu-latest\n    steps:\n    - name: Cache node modules\n      uses: actions/cache@v4\n      with:\n        path: ~/.npm\n        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}\n        restore-keys: v1-npm-deps-\n```\n\n## Artifacts\n\nGitLab CI/CD と GitHub Actions はどちらも、ジョブによって作成されたファイルとディレクトリを成果物としてアップロードできます。 GitHub Actions では、成果物を使用して、複数のジョブ間でデータを永続化できます。\n\n以下は、それぞれのシステムにおける構文の例です。\n\n### 成果物の GitLab CI/CD 構文\n\n```yaml\nscript:\nartifacts:\n  paths:\n    - math-homework.txt\n```\n\n### 成果物の GitHub Actions 構文\n\n```yaml\n- name: Upload math result for job 1\n  uses: actions/upload-artifact@v4\n  with:\n    name: homework\n    path: math-homework.txt\n```\n\n詳しくは、「[ワークフロー成果物を使ったデータの格納と共有](/ja/actions/using-workflows/storing-workflow-data-as-artifacts)」をご覧ください。\n\n## データベースとサービスコンテナ\n\nどちらのシステムでも、データベース、キャッシング、あるいはその他の依存関係のための追加コンテナを含めることができます。\n\nGitLab CI/CD ではジョブのコンテナーを `image` キーで指定しますが、GitHub Actions では `container` キーを使います。 どちらのシステムでも、追加のサービス コンテナーは `services` キーで指定します。\n\n以下は、それぞれのシステムにおける構文の例です。\n\n### データベースとサービス コンテナーの GitLab CI/CD 構文\n\n```yaml\ncontainer-job:\n  variables:\n    POSTGRES_PASSWORD: postgres\n    # The hostname used to communicate with the\n    # PostgreSQL service container\n    POSTGRES_HOST: postgres\n    # The default PostgreSQL port\n    POSTGRES_PORT: 5432\n  image: node:20-bookworm-slim\n  services:\n    - postgres\n  script:\n    # Performs a clean installation of all dependencies\n    # in the `package.json` file\n    - npm ci\n    # Runs a script that creates a PostgreSQL client,\n    # populates the client with data, and retrieves data\n    - node client.js\n  tags:\n    - docker\n```\n\n### データベースとサービス コンテナーの GitHub Actions 構文\n\n```yaml\njobs:\n  container-job:\n    runs-on: ubuntu-latest\n    container: node:20-bookworm-slim\n\n    services:\n      postgres:\n        image: postgres\n        env:\n          POSTGRES_PASSWORD: postgres\n\n    steps:\n      - name: Check out repository code\n        uses: actions/checkout@v6\n\n      # Performs a clean installation of all dependencies\n      # in the `package.json` file\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Connect to PostgreSQL\n        # Runs a script that creates a PostgreSQL client,\n        # populates the client with data, and retrieves data\n        run: node client.js\n        env:\n          # The hostname used to communicate with the\n          # PostgreSQL service container\n          POSTGRES_HOST: postgres\n          # The default PostgreSQL port\n          POSTGRES_PORT: 5432\n```\n\n詳しくは、「[Docker サービス コンテナーとの通信](/ja/actions/using-containerized-services/about-service-containers)」をご覧ください。"}