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