Migration de CircleCI vers Actions

CircleCI et 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 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 Actions ».

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 à 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 exécuteurs hébergés par , voir Utilisation des exécuteurs hébergés par .

CircleCI définit workflows dans le fichier config.yml, ce qui vous permet de configurer plusieurs workflows. 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 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 Actions équivalente. Pour plus d’informations, consultez « Workflow syntax for Actions ».

CircleCI et 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. 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 un code personnalisé qui interagit avec votre référentiel de la manière que vous souhaitez, y compris en intégrant les API de et toute API tierce publiquement disponible. 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. 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 ».

CircleCI et 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 Actions.

Nous vous recommandons d’abandonner les images prédéfinies de CircleCI lorsque vous migrez vers 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 ».

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

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

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

CircleCI et 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.

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

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

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

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

Voici un exemple de syntaxe de configuration CircleCI et 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@v4
  with:
    name: homework
    path: math-homework.txt

...

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

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

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. 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 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
        # 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..com/actions/using--hosted-runners/about--hosted-runners#docker-container-filesystem

      - name: Setup file system permissions
        run: sudo chmod -R 777 $_WORKSPACE / /__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 ».

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

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

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

Dans cet article