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 « ».
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 sur le système de fichiers Docker sur les exécuteurs hébergés par GitHub Enterprise Cloud, consultez « À propos 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 Cloud 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 Cloud 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 « Création d’actions ».
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 « Utilisation d’une matrice pour vos travaux ».
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 sur le système de fichiers Docker, consultez « À propos 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 « À propos 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 Cloud.
Pour plus d’informations, consultez « Variables » et « Secrets chiffrés ».
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.
CircleCI | GitHub Actions |
---|---|
|
|
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.
CircleCI | GitHub Actions |
---|---|
|
|
Pour plus d’informations, consultez « Stockage des données de workflow en tant qu’artefacts ».
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.
CircleCI | GitHub Actions |
---|---|
|
|
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.
CircleCI | GitHub Actions |
---|---|
|
|