Migration de CircleCI vers GitHub Actions

Introduction

CircleCI et GitHub Actions vous permettent tous deux de créer des flux de travail qui compilent, testent, publient, mettent en production et déploient le code. CircleCI et GitHub Actions partagez certaines similitudes dans la configuration du flux de travail :

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 « Présentation des 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 d'informations de chronométrage historiques. 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 sur le système de fichiers Docker sur les GitHubrunners hébergés, consultez Exécuteurs hébergés par GitHub.

Migration des workflows et des tâches

CircleCI définit workflows dans le fichier config.yml, ce qui vous permet de configurer plusieurs workflows. GitHub nécessite un fichier de flux de travail par flux de travail 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 à l’aide requires de votre workflow CircleCI, vous pouvez utiliser la syntaxe équivalente GitHub Actionsneeds . Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».

Migration d’orbs vers des actions

CircleCI et GitHub Actions fournit un mécanisme pour réutiliser et partager des tâches dans un flux de travail. 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 dispose de 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 référentiel de quelque manière que ce soit, y compris l’intégration avec GitHubles API de ' et toutes les API tierces disponibles 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 « Réutilisation des automatisations ».

CircleCI peut réutiliser des éléments de workflows avec des ancres et des alias YAML. GitHub Actions prend en charge les ancres et les alias YAML pour la réutilisation, et fournit également des matrices pour l’exécution de travaux avec différentes configurations. 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 d’étapes dans une image Docker.

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

Nous vous recommandons de vous éloigner des 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 « Exécuteurs hébergés par GitHub ».

Pour plus d’informations sur les outils et packages disponibles sur GitHubles images d’exécuteur hébergées, consultez Exécuteurs hébergés par GitHub.

Utilisation de variables et de secrets

CircleCI et GitHub Actions permettent de définir des variables dans le fichier de configuration et de créer des secrets à l’aide de l’interface utilisateur de CircleCI ou de GitHub.

Pour plus d’informations, consultez « Références des variables » et « Utilisation de secrets dans GitHub Actions ».

Mise en cache

CircleCI et GitHub Actions fournissez 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@v4
  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 de CircleCI (ou DLC).

Persistance des données entre les tâches

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

Vous trouverez ci-dessous un exemple dans circleCI et GitHub Actions la syntaxe de configuration.

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 conserver les données entre les travaux

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

...

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

Pour plus d’informations, consultez « Stocker et partager des données avec les artefacts de 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 répertorier des conteneurs supplémentaires dans services.

Ci-dessous figure 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@v6
      - 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 « Communication avec les conteneurs de service Docker ».

Exemple complet

Voici un exemple concret. À gauche, on voit le fichier config.yml actuel de CircleCI pour le dépôt thoughtbot/administrator. À droite s’affiche l’équivalent 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@v6
      - name: Setup Ruby
        uses: eregon/use-ruby-action@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
        with:
          ruby-version: ${{ matrix.ruby }}
      - name: Cache dependencies
        uses: actions/cache@v4
        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

Migration de CircleCI vers GitHub Actions

Dans cet article