Migration de CircleCI vers GitHub Actions

GitHub Actions et CircleCI partagent plusieurs similitudes de configuration, ce qui facilite grandement la migration vers GitHub Actions.

Dans cet article

Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.

Introduction

CircleCI et GitHub Actions vous permettent tous deux de créer des workflows qui génèrent, testent, publient, libèrent et déploient automatiquement du code. CircleCI et GitHub Actions partagent certaines similitudes dans la configuration de workflow :

  • Les fichiers de configuration de workflow sont écrits en YAML et stockés dans le dépôt.
  • Les workflows comportent un ou plusieurs travaux.
  • Les travaux incluent une ou plusieurs étapes ou commandes individuelles.
  • Les étapes ou les tâches peuvent être réutilisées et partagées avec la communauté.

Pour plus d’informations, consultez « Comprendre GitHub Actions ».

Différences clés

Lors de la migration à partir de CircleCI, tenez compte des différences suivantes :

  • Le parallélisme de test automatique de CircleCI regroupe automatiquement les tests en fonction des règles spécifiées par l’utilisateur ou des informations de durée d’historique. Cette fonctionnalité n’est pas intégrée à GitHub Actions.
  • Les actions qui s’exécutent dans des conteneurs Docker sont sensibles aux problèmes d’autorisations, car les conteneurs ont un mappage différent des utilisateurs. Vous pouvez éviter un grand nombre de ces problèmes en n’utilisant pas l’instruction USER dans votre Dockerfile. Pour plus d’informations à propos le système de fichiers Docker sur les exécuteurs hébergés sur GitHub Enterprise Server, consultez « Utilisation des exécuteurs hébergés par GitHub ».

Migration de workflows et de travaux

CircleCI définit workflows dans le fichier config.yml, ce qui vous permet de configurer plusieurs workflows. GitHub Enterprise Server nécessite un fichier de workflow par workflow et, par conséquent, ne vous oblige pas à déclarer workflows. Vous devez créer un fichier de workflow pour chaque workflow configuré dans config.yml.

CircleCI et GitHub Actions configurent jobs dans le fichier de configuration à l’aide d’une syntaxe similaire. Si vous configurez des dépendances entre les travaux avec requires dans votre workflow CircleCI, vous pouvez utiliser la syntaxe needs GitHub Actions équivalente. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».

Migration d’orbs vers des actions

CircleCI et GitHub Actions fournissent un mécanisme permettant de réutiliser et de partager des tâches dans un workflow. CircleCI utilise un concept appelé orbs, écrits en YAML, pour fournir des tâches que les utilisateurs peuvent réutiliser dans un workflow. GitHub Actions a des composants réutilisables puissants et flexibles appelés actions, que vous générez avec des fichiers JavaScript ou des images Docker. Vous pouvez créer des actions en écrivant du code personnalisé qui interagit avec votre dépôt comme vous le souhaitez, notamment en s’intégrant aux API de GitHub Enterprise Server et à n’importe quelle API tierce disponible publiquement. Par exemple, une action peut publier des modules npm, envoyer des alertes par SMS lors de la création de problèmes urgents ou déployer du code prêt pour la production. Pour plus d’informations, consultez « Partage des automatisations ».

CircleCI peut réutiliser des éléments de workflows avec des ancres et des alias YAML. GitHub Actions prend en charge le besoin le plus courant de réutilisation à l’aide de matrices. Pour plus d’informations sur les matrices, consultez « Exécution de variantes de tâches dans un workflow ».

Utilisation des images Docker

CircleCI et GitHub Actions prennent en charge l’exécution des étapes à l’intérieur d’une image Docker.

CircleCI fournit un ensemble d’images prédéfinies avec des dépendances communes. Ces images ont la valeur USER définie sur circleci, ce qui entraîne un conflit des autorisations avec GitHub Actions.

Nous vous recommandons d’abandonner les images prédéfinies de CircleCI lorsque vous migrez vers GitHub Actions. Dans de nombreux cas, vous pouvez utiliser des actions pour installer les dépendances supplémentaires dont vous avez besoin.

Pour plus d’informations à propos du système de fichiers Docker, consultez « Utilisation des exécuteurs hébergés par GitHub ».

Pour plus d’informations sur les outils et les packages disponibles dans les images des exécuteurs hébergés par GitHub, consultez « Utilisation des exécuteurs hébergés par GitHub ».

Utilisation de variables et de secrets

CircleCI et GitHub Actions prennent en charge la définition des variables dans le fichier de configuration et la création de secrets à l’aide de l’interface utilisateur CircleCI ou GitHub Enterprise Server.

Pour plus d’informations, consultez « Stocker des informations dans des variables » et « Utilisation de secrets dans GitHub Actions ».

Mise en cache

CircleCI et GitHub Actions fournissent une méthode pour mettre manuellement en cache les fichiers dans le fichier de configuration.

Voici un exemple de syntaxe pour chaque système.

Syntaxe CircleCI pour la mise en cache

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

Syntaxe GitHub Actions pour la mise en cache

- name: Cache node modules
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
    restore-keys: v1-npm-deps-

GitHub Actions n’a pas d’équivalent de la mise en cache de couche Docker (ou DLC) de CircleCI.

Persistance des données entre les travaux

CircleCI et GitHub Actions fournissent des mécanismes permettant de conserver des données entre les travaux.

Voici un exemple de syntaxe de configuration CircleCI et GitHub Actions.

Syntaxe CircleCI pour la persistance des données entre les travaux

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

...

- attach_workspace:
    at: /tmp/workspace

Syntaxe GitHub Actions pour la persistance des données entre les travaux

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

...

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

Pour plus d’informations, consultez « Stockage et partage des données d’un workflow ».

Utilisation de bases de données et de conteneurs de service

Les deux systèmes vous permettent d’inclure des conteneurs supplémentaires pour les bases de données, la mise en cache ou d’autres dépendances.

Dans CircleCI, la première image répertoriée dans config.yaml est l’image principale utilisée pour exécuter des commandes. GitHub Actions utilise des sections explicites : utiliser container pour le conteneur principal et lister des conteneurs supplémentaires dans services.

Voici un exemple de syntaxe de configuration CircleCI et GitHub Actions.

Syntaxe CircleCI pour l’utilisation de bases de données et de conteneurs de service

---
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

Syntaxe GitHub Actions pour l’utilisation de bases de données et de conteneurs de service

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
        # Add a health check
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5

    steps:
      # This Docker file changes sets USER to circleci instead of using the default user, so we need to update file permissions for this image to work on GH Actions.
      # See https://docs.github.com/actions/using-github-hosted-runners/about-github-hosted-runners#docker-container-filesystem

      - name: Setup file system permissions
        run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp
      - uses: actions/checkout@v4
      - 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

Pour plus d’informations, consultez « À propos des conteneurs de service ».

Exemple complet

Voici un exemple concret. Le côté gauche affiche le fichier config.yml CircleCI réel pour le dépôt thoughtbot/administrator. Le côté droit affiche l’équivalent dans GitHub Actions.

Exemple complet pour CircleCI

---
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

Exemple complet pour GitHub Actions

# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.
# Elles sont fournies par un tiers et régies par
# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.
# documentation en ligne.

# GitHub recommande d’épingler les actions à un SHA de commit.
# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.
# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.

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
        # Add a health check
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5

    steps:
      - uses: actions/checkout@v4
      - name: Setup Ruby
        uses: eregon/use-ruby-action@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
        with:
          ruby-version: ${{ matrix.ruby }}
      - name: Cache dependencies
        uses: actions/cache@v3
        with:
          path: vendor/bundle
          key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
      - name: Install postgres headers
        run: |
          sudo apt-get update
          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