Il m'arrive souvent de construire des pipelines pour compiler des projets en Java. Parfois, c'est open source, parfois non. Récemment, j'ai décidé d'essayer de transférer une partie de mes dépôts de Travis-CI et TeamCity vers GitHub Actions, et voici ce que cela a donné.
Qu'allons-nous automatiser
Pour commencer, nous avons besoin d'un projet à automatiser. Créons une petite application sur Spring Boot / Java 11 / Maven. Dans cet article, la logique de l'application ne nous intéresse pas du tout, ce qui compte, c'est l'infrastructure autour de l'application, donc un simple contrôleur REST API nous suffira.
Vous pouvez consulter les sources ici : toutes les étapes de construction du pipeline sont reflétées dans les pull requests de ce projet.
JIRA et planification
Il convient de mentionner que nous utilisons généralement JIRA comme tracker de tâches, donc créons un tableau distinct pour ce projet et ajoutons-y les premières tâches :
Nous allons revenir un peu plus tard sur ce que JIRA et GitHub peuvent offrir ensemble.
Automatisons la compilation du projet
Notre projet test est compilé via Maven, donc sa compilation est assez simple. Tout ce dont nous avons besoin, c'est de mvn clean package.
Pour ce faire avec GitHub Actions, nous devons créer un fichier dans le dépôt pour décrire notre workflow. Cela peut être fait avec un simple fichier yml. Je ne peux pas dire que j'aime "programmer en yml", mais que peut-on y faire ? Créons dans le répertoire .github/workflow/ un fichier build.yml dans lequel nous allons décrire les actions lors de la compilation de la branche principale :
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 — c'est la description de l'événement qui déclenchera notre script.
on: pull_request / push — cela signifie que ce workflow doit être exécuté à chaque envoi dans la branche principale et lors de la création de pull requests.
Ensuite, il y a une description des tâches (jobs) et des étapes d'exécution (steps) pour chaque tâche.
runs-on — ici nous pouvons choisir le système d'exploitation cible. Étonnamment, nous pouvons même choisir Mac OS, mais sur les dépôts privés, cela coûte assez cher (par rapport à Linux).
uses permet de réutiliser d'autres actions. Par exemple, grâce à l'action actions/setup-java, nous configurons l'environnement pour Java 11.
À l'aide de with Nous pouvons spécifier les paramètres avec lesquels nous lançons l'action, ce sont essentiellement des arguments qui seront passés à l'exécution.
Il ne reste plus qu'à lancer la construction du projet avec Maven : run: mvn -B clean package drapeau -B cela signifie que nous avons besoin du mode non interactif, pour que Maven ne nous demande pas quelque chose à un moment donné.
Génial ! Maintenant, à chaque commit dans la branche master, la construction du projet est lancée.
Automatisons l'exécution des tests.
La construction, c'est bien, mais en réalité, un projet peut se construire sans problème, mais ne pas fonctionner. Donc, la prochaine étape est d'automatiser l'exécution des tests. De plus, il est plutôt pratique de voir les résultats des tests lorsque l'on fait une révision de PR — vous savez que les tests passent et que personne n'a oublié, avant de faire le merge, d'exécuter sa branche.
Nous allons exécuter des tests lors de la création d'une pull request et lors du merge dans master, et nous ajouterons également la construction d'un rapport de couverture de 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 la couverture des tests, j'utilise codecov en association avec le plugin jacoco. Codecov a sa propre action, mais elle a besoin d'un token pour fonctionner avec notre pull request :
${{ secrets.CODECOV_TOKEN }} — nous rencontrerons encore cette construction plusieurs fois, secrets est un mécanisme de stockage de secrets sur GitHub, nous pouvons y indiquer des mots de passe/tokens/hôtes/urls et d'autres données qui ne devraient pas être exposées dans la base de code du dépôt.
Ajouter une variable dans secrets peut se faire dans les paramètres du dépôt sur GitHub :
Le token peut être obtenu sur Après vous être connecté via GitHub, pour ajouter un projet public, il vous suffit de suivre un lien de ce type : /[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.
Ajoutons le plugin jacoco dans le fichier POM :
org.jacoco
jacoco-maven-plugin
0.8.4
prepare-agent
report
test
report
org.apache.maven.plugins
maven-surefire-plugin
2.22.2
plain
**/*Test*.java
**/*IT*.java
Désormais, chaque demande de tirage aura un bot codecov qui ajoutera un graphique d'évolution de la couverture :
Ajoutons un analyseur statique
Dans la plupart de mes projets open source, j'utilise Sonar Cloud pour l'analyse statique du code, il est assez facile à connecter à Travis CI. Donc, c'est une étape logique lors de la migration vers GitHub Actions, de faire la même chose. Le marketplace des actions est une fonctionnalité sympa, mais cette fois-ci, il m'a un peu déçu, car j'ai par réflexe trouvé l'action dont j'avais besoin et l'ai écrite dans le workflow. Il s'est avéré que Sonar ne supporte pas le travail via une action pour analyser les projets utilisant Maven ou Gradle. Cela est bien sûr écrit dans la documentation, mais qui la lit ?!
Ce n'est pas possible via l'action, donc nous allons le faire via le plugin Maven :
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: Configurer JDK
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Analyser avec SonarCloud
# définir les variables d'environnement:
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
# exécuter le plugin Maven Sonar:
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 sur et doit être inscrit dans les secrets. GITHUB_TOKEN — c'est un jeton intégré généré par GitHub qui permettra à sonarcloud[bot] de s'authentifier dans Git, afin de nous laisser des messages dans les demandes de tirage.
Dsonar.projectKey — le nom du projet dans Sonar, que l'on peut voir dans les paramètres du projet.
Dsonar.organization — le nom de l'organisation sur GitHub.
Nous faisons une demande de tirage et attendons que sonarcloud[bot] vienne commenter :
Gestion des versions
Le build est configuré, les tests ont été exécutés, il est temps de procéder à la version. Voyons comment GitHub Actions aide à simplifier considérablement la gestion des versions.
Au travail, j'ai des projets dont la codebase est stockée dans Bitbucket (tout comme dans cette histoire « le jour j'écris dans Bitbucket, la nuit je commets sur GitHub »). Malheureusement, Bitbucket n'a pas d'outils intégrés pour gérer les versions. C'est un problème, car pour chaque version, je dois manuellement créer une page dans Confluence et y regrouper toutes les fonctionnalités incluses dans la version, fouiller dans les méandres de l'esprit, les tâches dans Jira, les commits dans le dépôt. Les chances de faire une erreur sont nombreuses; on peut oublier quelque chose ou écrire ce qui a déjà été publié la dernière fois. Parfois, il est simplement difficile de savoir à quelle catégorie rapporte un pull request — s'agit-il d'une fonctionnalité, d'un correctif de bogues, d'une modification de tests ou d'un élément d'infrastructure.
Comment GitHub Actions peut-il nous aider? Il existe une super action — Release Drafter, qui permet de définir un modèle de fichier de notes de version afin de configurer les catégories de pull requests et de les regrouper automatiquement dans le fichier de notes de version :
Exemple de modèle pour configurer le rapport (.github/release-drafter.yml) :
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' Nouvelles Fonctionnalités'
labels:
- 'type:features'
# nous rassemblons dans cette catégorie tous les PR avec l'étiquette type:features
- title: ' Corrections de Bogues'
labels:
- 'type:fix'
# de même pour l'étiquette type:fix, etc.
- title: ' Documentation'
labels:
- 'type:documentation'
- title: ' Configuration'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Changements
$CHANGES
Ajoutons un script pour générer un brouillon de version (.github/workflows/release-draft.yml) :
name: "Créer un brouillon de version"
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 }}
Tous les pull requests à partir de maintenant seront regroupés dans les notes de version automatiquement — magie !
Ici, une question peut se poser : que se passe-t-il si les développeurs oublient de décrire des étiquettes dans le PR ? Dans ce cas, il n'est pas clair dans quelle catégorie le classer, et il faudra de nouveau se pencher manuellement sur chacun des PR. Pour corriger ce problème, nous pouvons utiliser une autre action — Label Verifier — qui vérifie la présence d'étiquettes sur le pull request. S'il n'y a aucune étiquette obligatoire, le contrôle échouera et nous verrons un message à ce sujet dans notre pull request.
name: "Vérifier les étiquettes de type"
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, tout pull request doit être étiqueté avec l'une des étiquettes : type:fix, type:features, type:documentation, type:tests, type:config.
Auto-anotation des pull requests
Puisque nous avons abordé un sujet tel que le travail efficace avec les pull requests, il est également important de mentionner une action appelée labeler, qui attribue des étiquettes aux PR en fonction des fichiers modifiés. Par exemple, nous pouvons marquer comme [build] tout pull request contenant des modifications dans le répertoire .github/workflow.
Son intégration 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 aurons également besoin d'un fichier décrivant la correspondance entre les répertoires du projet et les thématiques des pull requests :
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 attribue automatiquement des étiquettes aux pull requests avec l'action qui vérifie la présence d'étiquettes requises, car match-label ne voit pas les étiquettes attribuées par le bot. Il semble plus simple d'écrire ma propre action combinant les deux étapes. Cependant, même dans cette configuration, c'est assez pratique, il suffit de choisir une étiquette dans la liste lors de la création d'un pull request.
Il est temps de déployer
J'ai essayé plusieurs options de déploiement via GitHub Actions (via ssh, via scp et à l'aide de docker-hub), et je peux dire que vous trouverez probablement un moyen de déployer le binaire sur le serveur, peu importe à quel point votre pipeline est tordu.
J'ai aimé l'idée de garder toute l'infrastructure au même endroit, donc voyons comment faire un déploiement dans GitHub Packages (c'est un dépôt pour le contenu binaire, npm, jar, docker).
Script pour construire l'image docker et la publier dans GitHub Packages :
nom: Déployer l'image docker
sur:
push:
branches:
- 'master'
emplois:
build_docker_image:
fonctionne-sur: ubuntu-18.04
étapes:
# Construire le JAR:
- utilise: actions/checkout@v1
- nom: configurer JDK 11
utilise: actions/setup-java@v1
avec:
java-version: 1.11
- nom: Packager Maven
exécuter: mvn -B clean compile package -DskipTests
# Définir des variables d'environnement globales:
- nom: définir env global
id: global_env
exécuter: |
echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*\/}"
echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com\/${GITHUB_REPOSITORY}\/${GITHUB_REPOSITORY#*\/}"
# Construire l'image Docker:
- nom: Construire et taguer l'image
exécuter: |
docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .
- nom: Connexion Docker
exécuter: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Publier l'image dans le dépôt de packages github:
- nom: Publier l'image
env:
IMAGE_NAME: $GITHUB_REPOSITORY
exécuter: docker push "docker.pkg.github.com\/$GITHUB_REPOSITORY\/${{ steps.global_env.outputs.IMAGE_NAME }}"
Tout d'abord, nous devons assembler le fichier JAR de notre application, après quoi nous calculons le chemin vers le registre docker de GitHub et le nom de notre image. Il y a quelques astuces ici auxquelles nous n'avons pas encore été confrontés :
- la construction de type : echo «::set-output name=NAME::VALUE» permet de définir la valeur d'une variable dans l'étape actuelle, afin qu'elle puisse être lue dans toutes les autres étapes.
- pour obtenir la valeur d'une variable définie à l'étape précédente, on peut utiliser l'identifiant de cette étape : ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- La variable standard GITHUB_REPOSITORY contient le nom du dépôt et son propriétaire (« owner/repo-name »). Pour extraire de cette chaîne tout sauf le nom du dépôt, nous allons utiliser la syntaxe bash : ${GITHUB_REPOSITORY#*\/}
Ensuite, nous devons construire l'image docker :
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
S'authentifier dans le registre :
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Et publier l'image dans le dépôt GitHub Packages :
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Pour spécifier la version de l'image, nous utilisons les premiers chiffres du hash SHA du commit — GITHUB_SHA a aussi ses nuances, si vous réalisez de telles constructions non seulement lors d'un merge dans master, mais également lors de la création d'une pull request, alors le SHA peut ne pas correspondre à l'empreinte que nous voyons dans l'historique git, car l'action actions/checkout crée son propre hash unique pour éviter les blocages mutuels dans les actions de la PR.
Si tout s'est bien passé, en ouvrant la section des packages (https://github.com/antkorwin/github-actions/packages) dans le dépôt, vous verrez la nouvelle image docker :
Vous pouvez également consulter la liste des versions de l'image Docker.
Il ne reste plus qu'à configurer notre serveur pour travailler avec ce registre et redémarrer le service. Je parlerai de la façon de le faire via systemd une autre fois.
Surveillance
Jetons un coup d'œil à une option simple pour effectuer un contrôle de santé de notre application à l'aide de GitHub Actions. Notre application de démarrage dispose d'un actuator, donc il n'est même pas nécessaire d'écrire une API pour vérifier son état, tout a déjà été fait pour les paresseux. Il suffit d'interroger 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 que nous devons faire est d'écrire une tâche pour vérifier le serveur par cron, et si jamais il ne répond pas, nous enverrons une notification sur Telegram.
Tout d'abord, examinons comment exécuter un workflow avec cron :
on:
schedule:
- cron: '*\/5 * * * *'
C'est simple, il est même difficile de croire que des événements peuvent être créés sur GitHub qui ne s'inscrivent pas du tout dans les webhooks. Les détails sont dans la documentation :
Nous allons vérifier l'état du serveur manuellement avec 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 "le contrôle de santé a échoué"
exit 1
fi
echo "C'est OK"
Nous stockons d'abord dans une variable la réponse du serveur à la requête, lors de l'étape suivante nous vérifions que le statut est UP et, si ce n'est pas le cas, nous sortons avec une erreur. Si vous devez « échouer » manuellement l'action, alors exit 1 — est une arme appropriée.
- name: send alert in telegram
if: ${{ failure() }}
uses: appleboy/telegram-action@master
with:
to: ${{ secrets.TELEGRAM_TO }}
token: ${{ secrets.TELEGRAM_TOKEN }}
message: |
Le contrôle de santé de :
${{secrets.SERVER_HOST}}/api/actuator/health
a échoué avec le résultat :
${{ steps.ping.outputs.status }}
Nous faisons l'envoi sur Telegram uniquement si l'action a échoué à l'étape précédente. Pour envoyer un message, nous utilisons appleboy/telegram-action, et vous pouvez lire dans la documentation comment obtenir le token du bot et l'id du chat :
N'oubliez pas de définir dans les secrets sur GitHub : l'URL du serveur et les tokens pour le bot Telegram.
Bonus track — JIRA pour les paresseux
J'ai promis que nous reviendrions à JIRA, et nous y sommes retournés. J'ai observé des centaines de fois lors des réunions quotidiennes des situations où les développeurs ont créé une fonctionnalité, fusionné la branche, mais ont oublié de déplacer la tâche dans JIRA. Bien sûr, si tout se faisait au même endroit, ce serait plus simple, mais en réalité, nous écrivons du code dans l'IDE, fusionnons des branches dans Bitbucket ou GitHub, et ensuite, nous déplaçons les tâches dans JIRA, ce qui nécessite d'ouvrir de nouvelles fenêtres, parfois de se reconnecter, etc. Quand tu te souviens bien de ce que tu dois faire ensuite, il n'est pas nécessaire d'ouvrir le tableau encore une fois. Au final, le matin, lors de la réunion, il faut passer du temps à actualiser le tableau des tâches.
GitHub nous aidera également dans cette tâche quotidienne. Pour commencer, nous pouvons automatiser le déplacement des tâches vers la colonne code_review lorsque nous soumettons une demande de tirage. Tout ce que nous avons à faire est de respecter l'accord sur la dénomination des branches :
[nom du projet]-[numéro de la tâche]-nom
par exemple, si la clé du projet « GitHub Actions » est GA, alors GA-8-jira-bot pourrait être la branche pour la mise en œuvre de la tâche GA-8.
L'intégration avec JIRA fonctionne via les actions d'Atlassian. Elles ne sont pas idéales, il faut dire que certaines d'entre elles n'ont pas fonctionné du tout pour moi. Mais nous ne discuterons que de celles qui fonctionnent réellement et qui sont utilisées activement.
Pour commencer, il faut procéder à l'authentification dans JIRA via 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 cela, il faut obtenir un token dans JIRA. Comment le faire est décrit ici :
On extrait l'identifiant de la tâche à partir 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 nom de la branche : $GITHUB_HEAD_REF
echo tâche extraite : ${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 "Veuillez nommer votre branche selon la tâche JIRA : [cle_du_projet]-[numero_tache]-nom_de_branche"
exit 1
fi
echo tâche JIRA trouvée avec succès : ${{steps.find_issue.outputs.ISSUE_ID}}
Si vous cherchez dans le marketplace GitHub, vous pouvez trouver une action pour cette tâche, mais j'ai dû écrire la même chose avec grep sur le nom de la branche, car cette action d'Atlassian n'a pas voulu fonctionner sur mon projet. Essayer de comprendre ce qui n'allait pas a pris plus de temps que de faire la même chose manuellement.
Il ne reste plus qu'à déplacer la tâche dans la colonne «Code review» lors de la création d'une pull request :
- name: Transitionner l'issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Pour cela, il existe une action spéciale sur GitHub, tout ce dont elle a besoin est l'identifiant de la tâche, obtenu à l'étape précédente, et une authentification dans JIRA, que nous avons effectuée ci-dessus.
De la même manière, il est possible de déplacer des tâches lors d'un merge dans master et à d'autres événements de workflow GitHub. En gros, tout dépend de votre imagination et de votre envie d'automatiser des processus répétitifs.
Conclusions
Si l'on regarde le diagramme classique DEVOPS, nous avons couvert toutes les étapes, sauf peut-être l'exploitation. Je pense que si nous essayons, nous pourrions trouver une action sur le marché pour l'intégration avec un système de support, donc considérons que le pipeline est solide et que son utilisation permet de tirer des conclusions.
Avantages :
- Le marketplace avec des actions prêtes à l'emploi pour toutes les situations est vraiment génial. Dans la plupart d'entre elles, vous pouvez également voir le code source pour comprendre comment résoudre un problème similaire ou poster une demande de fonctionnalité à l'auteur directement dans le dépôt GitHub.
- Le choix de la plateforme cible pour la construction : Linux, macOS, Windows est une fonctionnalité assez intéressante.
- GitHub Packages est une excellente chose, garder toute l'infrastructure au même endroit est pratique, pas besoin de naviguer à travers différentes fenêtres, tout est à portée de un ou deux clics de souris et parfaitement intégré avec GitHub Actions. Le support du docker registry dans la version gratuite est également un bon atout.
- GitHub cache les secrets dans les journaux de construction, donc l'utiliser pour stocker des mots de passe et des tokens n'est pas si effrayant que ça. Au cours de toutes mes expériences, je n'ai jamais réussi à voir un secret en clair dans la console.
- Gratuit pour les projets Open Source
Inconvénients :
- YML, je ne l'aime pas vraiment. Lorsque je travaille avec ce type de flux, mon message de commit le plus fréquent est «fix yml format», soit j'oublie de mettre une tabulation quelque part, soit j'écris pas à la bonne ligne. En gros, rester devant l'écran avec un rapporteur et une règle n'est pas la tâche la plus agréable.
- DEBUG, débugger le flux avec des commits, lancer des reconstructions et afficher dans la console n'est pas toujours pratique, mais c'est un peu le style de «vous êtes devenus exigeants», habitués à travailler avec des IDE confortables où l'on peut débugger tout ce qu'on veut.
- Vous pouvez écrire votre propre action sur n'importe quelle plateforme si vous l'emballez dans un conteneur Docker, mais le support natif est uniquement disponible pour JavaScript. C'est une question de goût, mais je préfèrerais autre chose que du JS.
Je vous rappelle que le dépôt contenant tous les scripts se trouve ici :
La semaine prochaine, je vais intervenir lors de la conférence Heisenbug 2020 Piter. Je parlerai non seulement de la manière d'éviter les erreurs lors de la préparation des données de test, mais je partagerai également mes secrets sur le travail avec des ensembles de données dans des applications Java !
Source : habr.com
