CircleCIからGitHub Actionsへの移行

GitHub ActionsとCircleCIには設定に相似点があるので、GitHub Actionsへの移行は比較的単純明快です。

ここには以下の内容があります:

はじめに
主要な差異
ワークフローとジョブの移行
orbsからアクションへの移行
Dockerイメージの利用
変数とシークレットの利用
キャッシング
ジョブ間でのデータの永続化
データベースとサービスコンテナの利用
完全な例

ノート: GitHub Actionsは、GitHub Enterprise Server 2.22で限定ベータとして利用可能でした。ベータは終了しました。 GitHub Actionsは、GitHub Enterprise Server 3.0以降で一般に利用可能になりました。詳しい情報については、GitHub Enterprise Server 3.0 のリリースノートを参照してください。

GitHub Enterprise Server 3.0以降へのアップグレードに関する詳しい情報については「GitHub Enterprise Serverのアップグレード」を参照してください。
アップグレード後のGitHub Actionsの設定に関する詳しい情報については、GitHub Enterprise Server 3.0のドキュメンテーションを参照してください。

ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHub public roadmapで、計画されている将来のサポートに関する詳しい情報を見ることができます。

はじめに

CircleCIとGitHub Actionsは、どちらも自動的にコードのビルド、テスト、公開、リリース、デプロイを行うワークフローを作成できます。 CircleCIとGitHub Actionsは、ワークフローの設定において似ているところがあります。

ワークフローの設定ファイルはYAMLで書かれ、リポジトリに保存されます。
ワークフローには1つ以上のジョブが含まれます。
ジョブには1つ以上のステップもしくは個別のコマンドが含まれます。
ステップもしくはタスクは、再利用とコミュニティとの共有が可能です。

詳しい情報については、「GitHub Actionsの中核的概念」を参照してください。

主要な差異

CircleCIから移行する際には、以下の差異を考慮してください。

CircleCIの自動テストの並列性は、ユーザが指定したルールもしくは過去のタイミングの情報に基づいて、自動的にテストをグループ化します。この機能はGitHub Actionsには組み込まれていません。
コンテナはユーザのマッピングが異なるので、Dockerコンテナ内で実行されるアクションは、権限の問題に敏感です。これらの問題の多くは、Dockerfile中でUSER命令を使わなければ回避できます。 GitHub Enterprise Serverホストランナー上の Docker のファイルシステムに関する詳しい情報については「GitHub Enterprise Server ホストランナーの仮想環境」を参照してください。

ワークフローとジョブの移行

CircleCIはconfig.ymlファイル中でworkflowsを定義するので、複数のワークフローを設定できます。 GitHub Enterprise Serverはワークフローごとに1つのワークフローファイルを必要とするので、結果としてworkflowsを宣言する必要がありません。それぞれのワークフローごとに、config.ymlで内で設定された新しいワークフローファイルを作成しなければなりません。

CircleCIとGitHub Actionsは、どちらも似た構文を使って設定ファイル中でjobsを設定します。 CircleCIワークフロー中でrequiresを使ってジョブ間の依存関係を設定しているなら、相当するGitHub Actionsのneeds構文を利用できます。詳細については、「GitHub Actionsのワークフロー構文」を参照してください。

orbsからアクションへの移行

CircleCIとGitHub Actionsは、どちらもワークフロー中のタスクを再利用し、共有するための仕組みを提供しています。 CircleCIはorbsという概念を利用します。これはYAMLで書かれ、ワークフロー中で再利用できるタスクを提供します。 GitHub Actionsはアクションと呼ばれる強力で柔軟な再利用できるコンポーネントを持っており、これはJavaScriptファイルもしくはDockerイメージで構築できます。 GitHub Enterprise Server の API やパブリックに利用可能なサードパーティ API との統合など、リポジトリと相互作用するカスタムコードを書いてアクションを作成することができます。たとえば、アクションでnpmモジュールを公開する、緊急のIssueが発生したときにSMSアラートを送信する、本番対応のコードをデプロイすることなどが可能です。詳細については、「アクションを作成する」を参照してください。

CircleCIは、YAMLのアンカーとエイリアスでワークフローの部分を再利用できます。 GitHub Actionsはビルドマトリックスを使って、再利用性についての一般的な要求のほとんどをサポートします。ビルドマトリックスに関する詳細な情報については「複雑なワークフローを管理する」を参照してください。

Dockerイメージの利用

CircleCIとGitHub Actionsは、どちらもDockerイメージ内でのステップの実行をサポートします。

CircleCIは、共通の依存関係を持つ一連のビルド済みのイメージを提供します。これらのイメージではUSERがcircleciに設定されており、それがGitHub Actionsとの権限の衝突を引き起こすことになります。

GitHub Actionsへの移行に際しては、CircleCIの構築済みイメージから離脱することをおすすめします。多くの場合、必要な追加の依存関係のインストールにアクションを使うことができます。

Dockerのファイルシステムに関する詳しい情報については「GitHub Enterprise Serverホストランナーの仮想環境」を参照してください。ー

GitHub ホストの仮想環境で使用できるツールとパッケージの詳細については、「GitHub ホストランナーの仕様」を参照してください。

変数とシークレットの利用

CircleCIとGitHub Actionsは、設定ファイル内での環境変数の設定と、CircleCIもしくはGitHub Enterprise ServerのUIを使ったシークレットの作成をサポートしています。

詳しい情報については「環境変数の利用」及び「暗号化されたシークレットの作成と利用」を参照してください。

キャッシング

CircleCIとGitHub Actionsは、設定ファイル中で手動でファイルをキャッシュする方法を提供しています。

以下は、それぞれのシステムにおける構文の例です。

CircleCI GitHub Actions

- restore_cache:
    keys:
      - v1-npm-deps-{{ checksum "package-lock.json" }}
      - v1-npm-deps-

- 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 キャッシュは、GitHub.com でホストされているリポジトリにのみ適用できます。詳しい情報については、「ワークフローを高速化するための依存関係のキャッシュ」を参照してください。

GitHub Actionsは、CircleCIのDocker Layer Caching（DLC）に相当する機能を持っていません。

ジョブ間でのデータの永続化

CircleCIとGitHub Actionsは、どちらもジョブ間でデータを永続化するための仕組みを提供しています。

以下は、CircleCIとGitHub Actionsの設定構文の例です。

CircleCI GitHub Actions

- persist_to_workspace:
    root: workspace
    paths:
      - math-homework.txt

...

- attach_workspace:
    at: /tmp/workspace

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

...

- name: Download math result for job 1
  uses: actions/download-artifact@v2
  with:
    name: homework

詳しい情報については「成果物を利用してワークフローのデータを永続化する」を参照してください。

データベースとサービスコンテナの利用

どちらのシステムでも、データベース、キャッシング、あるいはその他の依存関係のための追加コンテナを含めることができます。

CircleCIでは、config.yamlで最初に挙げられているイメージが、コマンドの実行に使われる主要なイメージです。 GitHub Actionsは明示的なセクションを使います。主要なコンテナにはcontainerを使い、追加のコンテナはservicesにリストしてください。

以下は、CircleCIとGitHub Actionsの設定構文の例です。

CircleCI GitHub Actions

---
version: 2.1

jobs:

  ruby-26:
    docker:
      - image: circleci/ruby:2.6.3-node-browsers-legacy
        environment:
          PGHOST: localhost
          PGUSER: administrate
          RAILS_ENV: test
      - image: postgres:10.1-alpine
        environment:
          POSTGRES_USER: administrate
          POSTGRES_DB: ruby26
          POSTGRES_PASSWORD: ""

    working_directory: ~/administrate

    steps:
      - checkout

      # Bundle install dependencies
      - run: bundle install --path vendor/bundle

      # Wait for DB
      - run: dockerize -wait tcp://localhost:5432 -timeout 1m

      # Setup the environment
      - run: cp .sample.env .env

      # Setup the database
      - run: bundle exec rake db:setup

      # Run the tests
      - run: bundle exec rake

workflows:
  version: 2
  build:
    jobs:
      - ruby-26
...

- attach_workspace:
    at: /tmp/workspace

name: Containers

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest
    container: circleci/ruby:2.6.3-node-browsers-legacy

    env:
      PGHOST: postgres
      PGUSER: administrate
      RAILS_ENV: test

    services:
      postgres:
        image: postgres:10.1-alpine
        env:
          POSTGRES_USER: administrate
          POSTGRES_DB: ruby25
          POSTGRES_PASSWORD: ""
        ports:
          - 5432:5432
        # ヘルスチェックを追加
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5

    steps:
      # このDockerファイルは、デフォルトユーザではなくUSERをcirceciに変更するので、このイメージのファイルの権限をGH Actionsで動作するように変更しなければならない。
      # https://docs.github.com/actions/reference/virtual-environments-for-github-hosted-runners#docker-container-filesystem を参照
      - name: Setup file system permissions
        run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp
      - uses: actions/checkout@v2
      - name: Install dependencies
        run: bundle install --path vendor/bundle
      - name: Setup environment configuration
        run: cp .sample.env .env
      - name: Setup database
        run: bundle exec rake db:setup
      - name: Run tests
        run: bundle exec rake

詳しい情報については「サービスコンテナについて」を参照してください。

完全な例

以下は実際の例です。左は thoughtbot/administratorリポジトリのための実際のconfig.ymlを示しています。右は、同等のGitHub Actionsを示しています。

CircleCI GitHub Actions

---
version: 2.1

commands:
  shared_steps:
    steps:
      - checkout

      # Restore Cached Dependencies
      - restore_cache:
          name: Restore bundle cache
          key: administrate-{{ checksum "Gemfile.lock" }}

      # Bundle install dependencies
      - run: bundle install --path vendor/bundle

      # Cache Dependencies
      - save_cache:
          name: Store bundle cache
          key: administrate-{{ checksum "Gemfile.lock" }}
          paths:
            - vendor/bundle

      # Wait for DB
      - run: dockerize -wait tcp://localhost:5432 -timeout 1m

      # Setup the environment
      - run: cp .sample.env .env

      # Setup the database
      - run: bundle exec rake db:setup

      # Run the tests
      - run: bundle exec rake

default_job: &default_job
  working_directory: ~/administrate
  steps:
    - shared_steps
    # Run the tests against multiple versions of Rails
    - run: bundle exec appraisal install
    - run: bundle exec appraisal rake

jobs:
  ruby-25:
    <<: *default_job
    docker:
      - image: circleci/ruby:2.5.0-node-browsers
        environment:
          PGHOST: localhost
          PGUSER: administrate
          RAILS_ENV: test
      - image: postgres:10.1-alpine
        environment:
          POSTGRES_USER: administrate
          POSTGRES_DB: ruby25
          POSTGRES_PASSWORD: ""

  ruby-26:
    <<: *default_job
    docker:
      - image: circleci/ruby:2.6.3-node-browsers-legacy
        environment:
          PGHOST: localhost
          PGUSER: administrate
          RAILS_ENV: test
      - image: postgres:10.1-alpine
        environment:
          POSTGRES_USER: administrate
          POSTGRES_DB: ruby26
          POSTGRES_PASSWORD: ""

workflows:
  version: 2
  multiple-rubies:
    jobs:
      - ruby-26
      - ruby-25

name: Containers

on: [push]

jobs:
  build:

    strategy:
      matrix:
        ruby: [2.5, 2.6.3]

    runs-on: ubuntu-latest

    env:
      PGHOST: localhost
      PGUSER: administrate
      RAILS_ENV: test

    services:
      postgres:
        image: postgres:10.1-alpine
        env:
          POSTGRES_USER: administrate
          POSTGRES_DB: ruby25
          POSTGRES_PASSWORD: ""
        ports:
          - 5432:5432
        # ヘルスチェックを追加
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5

    steps:
      - uses: actions/checkout@v2
      - name: Setup Ruby
        uses: eregon/use-ruby-action@master
        with:
          ruby-version: ${{ matrix.ruby }}
      - name: Cache dependencies
        uses: actions/cache@v2
        with:
          path: vendor/bundle
          key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
      - name: Install postgres headers
        run: sudo apt-get install libpq-dev
      - name: Install dependencies
        run: bundle install --path vendor/bundle
      - name: Setup environment configuration
        run: cp .sample.env .env
      - name: Setup database
        run: bundle exec rake db:setup
      - name: Run tests
        run: bundle exec rake
      - name: Install appraisal
        run: bundle exec appraisal install
      - name: Run appraisal
        run: bundle exec appraisal rake

CircleCIからGitHub Actionsへの移行

ここには以下の内容があります:

はじめに

主要な差異

ワークフローとジョブの移行

orbsからアクションへの移行

Dockerイメージの利用

変数とシークレットの利用

キャッシング

ジョブ間でのデータの永続化

データベースとサービスコンテナの利用

完全な例

Did this doc help you?

Help us make these docs great!

Still need help?