Cercles d'enfer avec GitHub Actions (création d'un pipeline CI/CD pour un projet Java)

Je dois souvent créer un pipeline pour créer des projets en Java. Parfois, c'est open source, parfois non. J'ai récemment décidé d'essayer de déplacer certains de mes référentiels de Travis-CI et TeamCity vers GitHub Actions, et voici ce qui en est ressorti.

Qu’allons-nous automatiser ?

Tout d'abord, nous avons besoin d'un projet que nous allons automatiser, créons une petite application sous Spring boot / Java 11 / Maven. Pour les besoins de cet article, nous ne nous intéresserons pas du tout à la logique de l'application ; l'infrastructure autour de l'application est importante pour nous, donc un simple contrôleur API REST nous suffira.

Vous pouvez consulter les sources ici : github.com/antkorwin/github-actions Toutes les étapes de la construction d'un pipeline sont reflétées dans les demandes de tirage pour ce projet.

JIRA et planification

Cela vaut la peine de dire que nous utilisons généralement JIRA comme outil de suivi des problèmes, créons donc un tableau séparé pour ce projet et ajoutons-y les premiers problèmes :

Un peu plus tard, nous reviendrons sur les choses intéressantes que JIRA et GitHub peuvent offrir en combinaison.

Nous automatisons l'assemblage du projet

Notre projet de test est construit via maven, donc sa construction est assez simple, tout ce dont nous avons besoin est le package mvn clean.

Pour ce faire en utilisant Github Actions, nous devrons créer un fichier dans le référentiel décrivant notre flux de travail, cela peut être fait avec un fichier yml ordinaire, je ne peux pas dire que j'aime la « programmation yml », mais que pouvons-nous faire - nous le faisons dans le répertoire .github/ workflow/ fichier build.yml dans lequel nous décrirons les actions lors de la construction de la branche master :

name: Build

on:
  pull_request:
    branches:
      - '*'
  push:
    branches:
      - 'master'

jobs:
  build:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v1
      - name: set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Maven Package
        run: mvn -B clean package -DskipTests

on — ceci est une description de l'événement sur lequel notre script sera lancé.

sur : pull_request/push — indique que ce workflow doit être lancé à chaque fois qu'un push est effectué vers le maître et que des pull request sont créées.

Voici une description des tâches (emplois) et les étapes d'exécution (mesures) pour chaque tâche.

fonctionne sur - ici nous pouvons sélectionner le système d'exploitation cible, étonnamment, vous pouvez même choisir Mac OS, mais sur les référentiels privés cela coûte assez cher (par rapport à Linux).

Usages vous permet de réutiliser d'autres actions, par exemple, en utilisant l'action actions/setup-java, nous installons l'environnement pour Java 11.

Au moyen de comprenant nous pouvons spécifier les paramètres avec lesquels nous lançons l'action, ce sont essentiellement les arguments qui seront transmis à l'action.

Il ne reste plus qu'à exécuter le build du projet avec Maven : run: mvn -B clean package drapeau -B dit qu'il faut un mode non interactif pour que le maven ne veuille plus nous demander quelque chose

Super! Désormais, chaque fois que vous vous engagez dans le maître, la construction du projet démarre.

Automatisation des lancements de tests

L'assemblage, c'est bien, mais en réalité, un projet peut être assemblé en toute sécurité, mais pas fonctionner. Par conséquent, l’étape suivante consiste à automatiser les tests. De plus, il est très pratique d'examiner les résultats de la réussite des tests lorsque vous effectuez une revue des relations publiques - vous savez avec certitude que les tests réussissent et personne n'a oublié d'exécuter sa branche avant de procéder à une fusion.

Nous exécuterons des tests lors de la création d'une pull request et fusionnerons dans le maître, et en même temps nous ajouterons la création d'un rapport sur la couverture du code.

name: Build

on:
  pull_request:
    branches:
      - '*'
  push:
    branches:
      - 'master'

jobs:
  build:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v1
      - name: set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Maven Verify
        run: mvn -B clean verify
      - name: Test Coverage
        uses: codecov/codecov-action@v1
        with:
          token: ${{ secrets.CODECOV_TOKEN }}

Pour couvrir les tests, j'utilise codecov en conjonction avec le plugin jacoco. codecov a sa propre action, mais il a besoin d'un jeton pour fonctionner avec notre pull request :

${{ secrets.CODECOV_TOKEN }} — nous verrons cette construction plus d'une fois, secrets est un mécanisme pour stocker des secrets dans GitHub, nous pouvons y écrire des mots de passe/jetons/hôtes/urls et d'autres données qui ne doivent pas être incluses dans la base de code du référentiel.

Vous pouvez ajouter une variable aux secrets dans les paramètres du référentiel sur GitHub :

Vous pouvez obtenir un jeton à codecov.io Après autorisation via GitHub, pour ajouter un projet public il vous suffit de suivre un lien comme celui-ci : Nom d'utilisateur GitHub/[nom du dépôt]. Un référentiel privé peut également être ajouté ; pour ce faire, vous devez donner les droits codecov à l'application dans Github.

Ajoutez le plugin jacoco au fichier POM :

<plugin>
	<groupId>org.jacoco</groupId>
	<artifactId>jacoco-maven-plugin</artifactId>
	<version>0.8.4</version>
	<executions>
		<execution>
			<goals>
				<goal>prepare-agent</goal>
			</goals>
		</execution>
		<!-- attached to Maven test phase -->
		<execution>
			<id>report</id>
			<phase>test</phase>
			<goals>
				<goal>report</goal>
			</goals>
		</execution>
	</executions>
</plugin>
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<version>2.22.2</version>
	<configuration>
		<reportFormat>plain</reportFormat>
		<includes>
			<include>**/*Test*.java</include>
			<include>**/*IT*.java</include>
		</includes>
	</configuration>
</plugin>

Maintenant, le robot codecov entrera chacune de nos demandes d'extraction et ajoutera un graphique de changement de couverture :

Ajoutons un analyseur statique

Dans la plupart de mes projets open source, j'utilise Sonar Cloud pour l'analyse de code statique, il est assez facile de se connecter à travis-ci. C'est donc une étape logique lors de la migration vers GitHub Actions de faire de même. Le marché de l'action est une chose sympa, mais cette fois, il m'a un peu déçu, car par habitude, j'ai trouvé l'action dont j'avais besoin et je l'ai ajoutée au flux de travail. Mais il s'est avéré que Sonar ne prend pas en charge l'action d'analyse de projets sur Maven ou Gradle. Bien sûr, cela est écrit dans la documentation, mais qui le lit ?!

Ce n'est pas possible via une action, nous allons donc le faire via le plugin mvn :

name: SonarCloud

on:
  push:
    branches:
      - master
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  sonarcloud:
    runs-on: ubuntu-16.04
    steps:
      - uses: actions/checkout@v1
      - name: Set up JDK
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Analyze with SonarCloud
#       set environment variables:
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
#       run sonar maven plugin:
        run: mvn -B verify sonar:sonar -Dsonar.projectKey=antkorwin_github-actions -Dsonar.organization=antkorwin-github -Dsonar.host.url=https://sonarcloud.io -Dsonar.login=$SONAR_TOKEN -Dsonar.coverage.jacoco.xmlReportPaths=./target/site/jacoco/jacoco.xml

SONAR_TOKEN - peut être obtenu à sonarcloud.io et vous devez l'enregistrer dans les secrets. GITHUB_TOKEN - il s'agit d'un jeton intégré généré par GitHub, à l'aide duquel sonarcloud[bot] pourra se connecter à Git afin de nous laisser des messages dans les pull request.

Dsonar.projectKey — le nom du projet dans le sonar, vous pouvez le voir dans les paramètres du projet.

Dsonar.organisation — nom de l'organisation de GitHub.

Nous faisons une pull request et attendons que sonarcloud[bot] vienne dans les commentaires :

la gestion de sortie

Le build a été configuré, les tests ont été exécutés et nous pouvons publier une version. Voyons comment GitHub Actions peut rendre la gestion des versions beaucoup plus facile.

Au travail, j'ai des projets dont la base de code est dans bitbucket (tout est comme dans cette histoire « J'écris sur bitbucket pendant la journée, je m'engage sur GitHub la nuit »). Malheureusement, bitbucket ne dispose pas d'outils de gestion des versions intégrés. C'est un problème, car pour chaque version, vous devez créer manuellement une page dans confluence et y jeter toutes les fonctionnalités incluses dans la version, rechercher dans les palais de l'esprit, les tâches dans jira, les commits dans le référentiel. Il y a de nombreuses chances de faire une erreur, vous pouvez oublier quelque chose ou saisir quelque chose qui a déjà été publié la dernière fois, parfois on ne sait tout simplement pas comment classer une pull request - s'agit-il d'une fonctionnalité ou d'une correction de bug, ou d'une édition de tests, ou quelque chose d'infrastructurel.

Comment les actions GitHub peuvent-elles nous aider ? Il existe une excellente action - Release Drafter, elle vous permet de définir un modèle de fichier de notes de version pour définir des catégories de demandes d'extraction et de les regrouper automatiquement dans le fichier de notes de version :

Exemple de modèle pour configurer un rapport (.github/release-drafter.yml) :

name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
  - title: ' New Features'
    labels:
      - 'type:features'
# в эту категорию собираем все PR с меткой type:features

  - title: ' Bugs Fixes'
    labels:
      - 'type:fix'
# аналогично для метки type:fix и т.д.

  - title: ' Documentation'
    labels:
      - 'type:documentation'

  - title: ' Configuration'
    labels:
      - 'type:config'

change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
  ## Changes
  $CHANGES

Ajoutez un script pour générer un brouillon de version (.github/workflows/release-draft.yml) :

name: "Create draft release"

on:
  push:
    branches:
      - master

jobs:
  update_draft_release:
    runs-on: ubuntu-18.04
    steps:
      - uses: release-drafter/release-drafter@v5
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

À partir de maintenant, toutes les demandes de tirage seront automatiquement collectées dans les notes de version - c'est magique !

Ici, la question peut se poser : et si les développeurs oublient de mettre des balises dans le PR ? Ensuite, il n'est pas clair dans quelle catégorie le mettre, et encore une fois, vous devrez le gérer manuellement, avec chaque PR séparément. Pour résoudre ce problème, nous pouvons utiliser une autre action - le vérificateur d'étiquettes - qui vérifie la présence de balises sur la demande d'extraction. S'il n'y a pas de balises requises, la vérification échouera et nous verrons un message à ce sujet dans notre pull request.

name: "Verify type labels"

on:
  pull_request:
    types: [opened, labeled, unlabeled, synchronize]

jobs:
  triage:
    runs-on: ubuntu-18.04
    steps:
      - uses: zwaldowski/match-label-action@v2
        with:
          allowed: 'type:fix, type:features, type:documentation, type:tests, type:config'

Désormais, toute demande d'extraction doit être marquée avec l'une des balises : type:fix, type:features, type:documentation, type:tests, type:config.

Annotation automatique des demandes d'extraction

Puisque nous avons abordé un sujet tel que le travail efficace avec les demandes d'extraction, cela vaut la peine de parler d'une action telle que l'étiquetage, qui place des balises dans PR en fonction des fichiers qui ont été modifiés. Par exemple, nous pouvons marquer comme [build] toute demande d'extraction contenant des modifications apportées au répertoire .github/workflow.

Le connecter est assez simple :

name: "Auto-assign themes to PR"

on:
  - pull_request

jobs:
  triage:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/labeler@v2
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

Nous avons également besoin d'un fichier décrivant la correspondance entre les répertoires du projet et les sujets des pull request :

theme:build:
  - ".github/**"
  - "pom.xml"
  - ".travis.yml"
  - ".gitignore"
  - "Dockerfile"

theme:code:
  - "src/main/*"

theme:tests:
  - "src/test/*"

theme:documentation:
  - "docs/**"

theme:TRASH:
  - ".idea/**"
  - "target/**"

Je n'ai pas réussi à associer l'action qui place automatiquement les étiquettes dans les pull request avec l'action qui vérifie la présence des étiquettes requises ; match-label ne veut pas voir les étiquettes ajoutées par le bot. Il semble plus facile d’écrire sa propre action combinant les deux étapes. Mais même sous cette forme, il est assez pratique à utiliser : vous devez sélectionner une étiquette dans la liste lors de la création d'une pull request.

Il est temps de déployer

J'ai essayé plusieurs options de déploiement via GitHub Actions (via ssh, via scp et en utilisant docker-hub), et je peux dire que, très probablement, vous trouverez un moyen de télécharger le binaire sur le serveur, peu importe à quel point votre pipeline est tordu. est.

J'ai aimé l'option de conserver toute l'infrastructure au même endroit, voyons donc comment déployer sur les packages GitHub (il s'agit d'un référentiel pour le contenu binaire, npm, jar, docker).

Script pour créer une image Docker et la publier dans les packages GitHub :

name: Deploy docker image

on:
  push:
    branches:
      - 'master'

jobs:

  build_docker_image:
    runs-on: ubuntu-18.04
    steps:

#     Build JAR:
      - uses: actions/checkout@v1
      - name: set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Maven Package
        run: mvn -B clean compile package -DskipTests

#     Set global environment variables:
      - name: set global env
        id: global_env
        run: |
          echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*/}"
          echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*/}"

#     Build Docker image:
      - name: Build and tag image
        run: |
          docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .

      - name: Docker login
        run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

#     Publish image to github package repository:
      - name: Publish image
        env:
          IMAGE_NAME: $GITHUB_REPOSITORY
        run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"

Tout d’abord, nous devons créer le fichier JAR de notre application, après quoi nous calculons le chemin d’accès au registre Docker GitHub et le nom de notre image. Il y a quelques astuces ici que nous n'avons pas encore rencontrées :

• une construction comme : echo « ::set-output name=NAME::VALUE » permet de définir la valeur d'une variable dans l'étape en cours, afin qu'elle puisse ensuite être lue dans toutes les autres étapes.
• vous pouvez obtenir la valeur de la variable définie à l'étape précédente via l'identifiant de cette étape : ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• La variable standard GITHUB_REPOSITORY stocke le nom du référentiel et son propriétaire («owner/repo-name»). Afin de tout supprimer de cette ligne sauf le nom du dépôt, nous utiliserons la syntaxe bash : ${GITHUB_REPOSITORY#*/}

Ensuite, nous devons créer l'image Docker :

docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"

Connectez-vous au registre :

docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

Et publiez l'image dans le référentiel de packages GitHub :

docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"

Afin d'indiquer la version de l'image, nous utilisons les premiers chiffres du hachage SHA du commit - GITHUB_SHA il y a aussi des nuances ici, si vous effectuez de telles builds non seulement lors de la fusion dans master, mais également selon la création de la pull request événement, alors SHA peut ne pas correspondre au hachage que nous voyons dans l'historique git, car l'action actions/checkout crée son propre hachage unique pour éviter les actions de blocage dans le PR.

Si tout s'est bien passé, en ouvrant la section packages (https://github.com/antkorwin/github-actions/packages) dans le référentiel, vous verrez une nouvelle image docker :

Là, vous pouvez également voir une liste des versions de l'image Docker.

Il ne reste plus qu'à configurer notre serveur pour qu'il fonctionne avec ce registre et redémarrer le service. Je parlerai probablement de la façon de procéder via systemd une autre fois.

Surveillance

Examinons une option simple sur la façon d'effectuer un bilan de santé pour notre application à l'aide des actions GitHub. Notre application de démarrage dispose d'un actionneur, nous n'avons donc même pas besoin d'écrire une API pour vérifier son état ; nous avons déjà tout fait pour les paresseux. Il vous suffit de retirer l'hôte : SERVER-URL:PORT/actuator/health

$ curl -v 127.0.0.1:8080/actuator/health

> GET /actuator/health HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.61.1
> Accept: */*

< HTTP/1.1 200
< Content-Type: application/vnd.spring-boot.actuator.v3+json
< Transfer-Encoding: chunked
< Date: Thu, 04 Jun 2020 12:33:37 GMT

{"status":"UP"}

Tout ce dont nous avons besoin est d'écrire une tâche pour vérifier le serveur à l'aide de cron, et si soudainement il ne nous répond pas, nous enverrons une notification par télégramme.

Tout d'abord, voyons comment exécuter un workflow cron :

on:
  schedule:
    - cron:  '*/5 * * * *'

C'est simple, je n'arrive même pas à croire que dans Github on puisse créer des événements qui ne rentrent pas du tout dans les webhooks. Les détails sont dans la documentation : help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

Vérifions l'état du serveur manuellement via curl :

jobs:
  ping:
    runs-on: ubuntu-18.04
    steps:

      - name: curl actuator
        id: ping
        run: |
          echo "::set-output name=status::$(curl ${{secrets.SERVER_HOST}}/api/actuator/health)"

      - name: health check
        run: |
          if [[ ${{ steps.ping.outputs.status }} != *"UP"* ]]; then
            echo "health check is failed"
            exit 1
          fi
          echo "It's OK"

Tout d'abord, nous enregistrons dans une variable ce que le serveur a répondu à la requête, à l'étape suivante nous vérifions que le statut est UP et, si ce n'est pas le cas, nous quittons avec une erreur. Si vous avez besoin de « submerger » une action avec vos mains, alors sortie 1 - une arme adaptée.

  - name: send alert in telegram
    if: ${{ failure() }}
    uses: appleboy/telegram-action@master
    with:
      to: ${{ secrets.TELEGRAM_TO }}
      token: ${{ secrets.TELEGRAM_TOKEN }}
      message: |
        Health check of the:
        ${{secrets.SERVER_HOST}}/api/actuator/health
        failed with the result:
        ${{ steps.ping.outputs.status }}

Nous envoyons au télégramme uniquement si l'action a échoué à l'étape précédente. Pour envoyer un message, nous utilisons appleboy/telegram-action ; vous pouvez découvrir comment obtenir un jeton de bot et un identifiant de chat dans la documentation : github.com/appleboy/telegram-action

N'oubliez pas d'écrire les secrets sur Github : URL du serveur et tokens pour le bot télégramme.

Piste bonus - JIRA pour les paresseux

J'avais promis que nous reviendrions sur JIRA, et nous sommes revenus. Des centaines de fois, j'ai observé une situation lors de stand-ups où des développeurs créaient une fonctionnalité, fusionnaient une branche, mais oubliaient de faire glisser le problème dans JIRA. Bien sûr, si tout cela était fait au même endroit, ce serait plus facile, mais en fait, nous écrivons du code dans l'EDI, fusionnons les branches dans bitbucket ou GitHub, puis faisons glisser les tâches dans Jira, pour cela, nous devons ouvrir de nouvelles fenêtres , reconnectez-vous parfois, etc. Lorsque vous vous souvenez parfaitement de ce que vous devez faire ensuite, il ne sert à rien d'ouvrir à nouveau le tableau. En conséquence, le matin, lors d'un stand-up, vous devez passer du temps à mettre à jour le tableau des tâches.

GitHub nous aidera également dans cette tâche de routine ; pour commencer, nous pouvons faire glisser automatiquement les problèmes dans la colonne code_review lorsque nous soumettons une pull request. Tout ce que vous avez à faire est de suivre la convention de dénomination des branches :

[имя проекта]-[номер таска]-название

par exemple, si la clé du projet « GitHub Actions » est GA, alors GA-8-jira-bot pourrait être une branche pour la mise en œuvre de la tâche GA-8.

L'intégration avec JIRA fonctionne grâce aux actions d'Atlassian, elles ne sont pas parfaites, je dois dire que certaines d'entre elles n'ont pas du tout fonctionné pour moi. Mais nous ne discuterons que de ceux qui fonctionnent réellement et sont activement utilisés.

Vous devez d'abord vous connecter à JIRA en utilisant l'action : atlassian/gajira-login

jobs:
  build:
    runs-on: ubuntu-latest
    name: Jira Workflow
    steps:
      - name: Login
        uses: atlassian/gajira-login@master
        env:
          JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
          JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
          JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}

Pour ce faire, vous devez obtenir un jeton dans JIRA, comment procéder est décrit ici : confluence.atlassian.com/cloud/api-tokens-938839638.html

Nous extrayons l'identifiant de la tâche du nom de la branche :

  - name: Find Issue
    id: find_issue
    shell: bash
    run: |
      echo "::set-output name=ISSUE_ID::$(echo ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}')"
      echo brach name: $GITHUB_HEAD_REF
      echo extracted issue: ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}'

  - name: Check Issue
    shell: bash
    run: |
      if [[ "${{steps.find_issue.outputs.ISSUE_ID}}" == "" ]]; then
        echo "Please name your branch according to the JIRA issue: [project_key]-[task_number]-branch_name"
        exit 1
      fi
      echo succcessfully found JIRA issue: ${{steps.find_issue.outputs.ISSUE_ID}}

Si vous effectuez une recherche sur le marché GitHub, vous pouvez trouver une action pour cette tâche, mais j'ai dû écrire la même chose en utilisant grep en utilisant le nom de la branche, car cette action d'Atlassian ne voulait en aucun cas travailler sur mon projet. , pour comprendre ce qui n'allait pas là-bas - plus longtemps que de faire la même chose avec vos mains.

Il ne reste plus qu'à déplacer la tâche vers la colonne « Revue de code » lors de la création d'une pull request :

  - name: Transition issue
    if: ${{ success() }}
    uses: atlassian/gajira-transition@master
    with:
      issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
      transition: "Code review"

Il existe une action spéciale pour cela sur GitHub, il suffit de l'ID de problème obtenu à l'étape précédente et de l'autorisation dans JIRA que nous avons effectuée ci-dessus.

De la même manière, vous pouvez faire glisser des tâches lors de la fusion dans le maître et d'autres événements du workflow GitHub. En général, tout dépend de votre imagination et de votre désir d'automatiser les processus de routine.

résultats

Si vous regardez le diagramme DEVOPS classique, nous avons couvert toutes les étapes, sauf peut-être le fonctionnement, je pense que si vous essayez, vous pouvez trouver une action sur le marché pour l'intégration avec le système d'assistance, nous supposerons donc que le pipeline s'est transformé en s'avère exhaustif et des conclusions peuvent être tirées sur la base de son utilisation.

Avantages:

• Marketplace avec des actions toutes faites pour toutes les occasions, c'est très cool. Dans la plupart d'entre eux, vous pouvez également consulter le code source pour comprendre comment résoudre un problème similaire ou publier une demande de fonctionnalité à l'auteur directement dans le référentiel GitHub.
• La sélection de la plateforme cible pour l'assemblage : Linux, Mac OS, Windows est une fonctionnalité assez intéressante.
• Les packages Github sont une bonne chose, c'est pratique de conserver toute l'infrastructure au même endroit, vous n'avez pas besoin de surfer dans différentes fenêtres, tout se trouve dans un rayon d'un ou deux clics de souris et est parfaitement intégré aux actions GitHub. La prise en charge du registre Docker dans la version gratuite est également un bon avantage.
• GitHub cache des secrets dans les journaux de build, donc l'utiliser pour stocker des mots de passe et des jetons n'est pas si effrayant. Au cours de toutes mes expériences, je n'ai jamais pu voir le secret à l'état pur dans la console.
• Gratuit pour les projets Open Source

Inconvénients:

• YML, eh bien, je ne l'aime pas. Lorsque je travaille avec un tel flux, le message de validation le plus courant que j'ai est « corriger le format yml », puis vous oubliez de mettre un onglet quelque part, ou vous l'écrivez sur la mauvaise ligne. En général, s’asseoir devant un écran avec un rapporteur et une règle n’est pas l’expérience la plus agréable.
• DEBUG, déboguer le flux avec des commits, exécuter une reconstruction et sortir sur la console n'est pas toujours pratique, mais il s'agit plutôt de la catégorie « vous en avez trop fait » ; vous êtes habitué à travailler avec IDEA pratique, quand vous pouvez déboguer n'importe quoi. .
• Vous pouvez écrire votre action sur n'importe quoi si vous l'encapsulez dans Docker, mais seul javascript est pris en charge nativement, bien sûr, c'est une question de goût, mais je préférerais autre chose que js.

Permettez-moi de vous rappeler que le référentiel avec tous les scripts se trouve ici : github.com/antkorwin/github-actions

La semaine prochaine, je jouerai avec rapport à la conférence Heisenbug 2020 Piter. Je vais vous expliquer non seulement comment éviter les erreurs lors de la préparation des données de test, mais aussi partager mes secrets de travail avec des ensembles de données dans les applications Java !

Source: habr.com