web-dev-qa-db-fra.com

Quelles sont les différences entre les actions GitHub et d'autres outils CI comme Jenkins?

GitHub a annoncé une fonctionnalité à venir, Actions GitHub .

Je suis positif sur les avantages des outils CI comme Jenkins pour la construction ou les tests automatiques, pour lesquels GitHub Actions est destiné à être utilisé à l'avenir.

Avoir un référentiel sur GitHub et utiliser un outil CI externe a l'énorme avantage de permettre de déplacer le référentiel vers une autre plateforme de référentiel Git (ou même locale) sans réécrire tout le processus CI. Avec GitHub Actions, vous êtes plus ou moins lié à l'écosystème GitHub.

Je suppose que l'intégration des actions de GitHub sera plus fluide dans l'environnement natif , mais y a-t-il d'autres avantages ou inconvénients à part cela?

githubcontinuous-integrationgithub-actions
16
Bennett Dams

Je travaille avec les actions GitHub à temps plein depuis quelques mois maintenant.

C'est encore tôt (juin 2019), mais voici ma liste:

Avantages:

  1. Les actions GitHub ne sont que des exécutions de docker consécutives. Très facile à raisonner et à déboguer. Reproduire l'environnement de construction pour Travis basé sur un conteneur est possible , mais plus difficile. Sur les actions GitHub, c'est juste un docker builddocker run une façon.
  2. Les actions individuelles d'un workflow sont isolées par défaut. Vous pouvez utiliser un environnement informatique complètement différent pour, disons, la compilation et les tests. Travis CI (et je pense que d'autres CI "traditionnels") exécuteraient toutes les "étapes" (~ actions) dans le même environnement informatique. Encore une fois, les actions GitHub sont beaucoup plus faciles à raisonner et à déboguer.
  3. Le main.workflow spec (un sous-ensemble du HCL et vraiment juste un graphe acyclique dirigé) est open source . Le tout est une enveloppe assez mince autour de Docker de toute façon, donc le verrouillage de la plate-forme est sans doute minimal.
  4. Il existe déjà réimplémentations open-source des actions GitHub, telles que act pour les tests locaux.
  5. Vous avez un accès rapide à l'API GitHub avec une authentification (quelque peu limitée) prête à l'emploi.
  6. Il peut y avoir une communauté dynamique (marché?) Où les gens peuvent partager des actions. Par exemple, je réutilise des actions de déploiement créées par différentes personnes dans différents écosystèmes.
  7. Un graphique acyclique dirigé (DAG) et l'éditeur visuel pour main.workflows est peut-être un bon moyen de modéliser CI/CD en particulier et les workflows en général. Prend un certain temps pour s'y habituer, mais se généralise bien.
  8. Les actions GitHub peuvent faire bien plus que du CI! Vous avez essentiellement toute l'API à portée de main en tant qu'entrées et sorties.

Désavantages:

Les actions GitHub (toujours?) Ont parfois des limites fondamentales surprenantes à ce stade (juin 2019).

  1. Pas de mise en cache native. Vous obtenez l'image et la mise en cache des couches (c'est compliqué ), mais rien d'autre. Pour les artefacts de construction, vous devez rouler votre propre cache (via AWS, Azure, etc ...), ce qui peut représenter beaucoup de travail. (Vous pouvez voir un configuration hacky ici .
  2. Étonnamment, aucune prise en charge des demandes de tirage des fourches . C'est encore un peu compliqué , et compréhensible du point de vue de la sécurité, mais il n'est actuellement pas possible d'exécuter des actions a) contre les secrets du dépôt de réception d'un fork PR (base), et/ou b) contre le résultat de fusion d'un PR de fourche (c'est ce que fait travis). Pour un workflow impliquant des fourches, cela rend les actions GitHub largement inutilisables en tant qu'outil CI/CD.
  3. Plate-forme unique, c'est tout ce que vous pouvez exécuter dans docker, donc une distribution Linux. Cela semble peu susceptible de changer, mais pourrait être une limitation acceptable. Vous pouvez toujours ajouter une action pour appeler d'autres services CI/CD multiplateforme.
  4. La documentation est encore assez clairsemée. Pas beaucoup de bonnes pratiques ou d'échafaudages.
  5. La qualité et l'étendue des actions GitHub publiées (au moins sur le marché) sont encore assez faibles/limitées. Nous verrons si cela décolle.
  6. Pas un bon moyen d'effectuer des tests unitaires. (J'ai piraté quelque chose ensemble, mais je n'en suis pas trop sûr).
10
maxheld

Avoir un référentiel sur GitHub et utiliser un outil CI externe a l'énorme avantage de permettre de déplacer le référentiel vers une autre plateforme de référentiel Git (ou même locale) sans réécrire tout le processus CI.
Avec GitHub Actions, vous êtes plus ou moins lié à l'écosystème GitHub.

Oui, et à partir de novembre 2019, un peu moins:

Voir Joe Bourne 'annonce " Les coureurs auto-hébergés pour les actions GitHub sont maintenant en version bêta ".

Vous pouvez avoir des coureurs auto-hébergés, ce qui signifie:

  • Votre environnement, vos outils ,
  • Machine ou configuration de toute taille ,
  • Accès sécurisé et mise en réseau ,
  • Prise en charge importante de la charge de travail .

Pour prendre en charge l'utilisation de runners auto-hébergés dans vos workflows, nous avons élargi l'expérience d'utilisation de runs-on clé.
Lors de l'inscription de vos coureurs auto-hébergés, ils reçoivent chacun une étiquette en lecture seule auto-hébergée que vous pouvez utiliser avec runs-on.
Voici un exemple:

# Use Any available Self-hosted runners connected to repo
runs-on: self-hosted

Voir la documentation sur " Hébergement de vos propres coureurs ".

1
VonC