Vos pipelines sont propres, vos tests unitaires passent, et pourtant la mise en production reste artisanale : un développeur ouvre Hop GUI, lance les tests à la main, puis copie les fichiers .hpl et .hwf vers le serveur par SFTP. Personne ne sait exactement quelle version tourne en production, ni si les tests ont réellement été rejoués avant la bascule. Le jour où un transform est modifié sans être retesté, l’erreur n’apparaît qu’en production, sur des données réelles.
La bonne nouvelle, c’est qu’un projet Apache Hop est constitué de fichiers texte et se pilote entièrement en ligne de commande. Tout ce qu’il faut pour une chaîne d’intégration continue est donc déjà là. Cet article détaille comment reconstituer un projet Hop sur un agent de build, y exécuter les tests unitaires sans interface graphique, et faire échouer la chaîne dès qu’un test tombe.
Prérequis
- Apache Hop 2.19.0 (version stable publiée le 17 août 2026) et un runtime Java 64 bits en version 21, exigé par cette version de Hop.
- Un projet Hop déjà structuré en projet et environnement, et au moins un test unitaire défini avec des jeux de données d’entrée et des golden data.
- Un dépôt Git et un exécuteur de chaîne CI/CD (GitLab CI, GitHub Actions, Jenkins : le principe est identique).
1. Ce qui doit entrer dans le dépôt Git
Un projet Hop se versionne comme du code, à condition de trancher clairement entre ce qui décrit la solution et ce qui décrit la machine qui l’exécute.
| Élément | Dans Git ? | Pourquoi |
Pipelines .hpl et workflows .hwf |
Oui | Ce sont vos livrables, lisibles en revue de code. |
| Dossier de métadonnées du projet | Oui | Connexions, configurations d’exécution, définitions de tests : la solution ne fonctionne pas sans. |
project-config.json |
Oui | Décrit le projet lui-même (chemins de métadonnées, jeux de données, tests). |
| Jeux de données CSV des tests | Oui | Sans eux, aucun test n’est rejouable. |
| Fichier de configuration d’environnement | Selon le contenu | Oui s’il ne contient que des chemins et des drapeaux ; jamais s’il contient des identifiants. |
hop-config.json de l’installation |
Non | Il décrit le poste ou l’agent, pas le projet. Il sera régénéré à chaque build. |
La règle qui évite les ennuis : le dépôt contient le projet, l’agent de build reconstruit l’installation. Les identifiants de connexion, eux, restent dans les variables secrètes de votre outil CI/CD et sont injectés au moment de l’exécution.
2. Reconstituer projet et environnement sur l’agent
Une installation Hop fraîchement décompressée ne connaît aucun projet. C’est le rôle de hop-conf, qui expose en ligne de commande ce que Hop GUI fait via son interface. Les options utiles ici sont --project-create et --environment-create.
# Enregistrer le projet issu du dépôt cloné
sh hop-conf.sh --project-create \
--project ventes \
--project-home /builds/ventes
# Déclarer un environnement dédié à l'intégration continue
sh hop-conf.sh \
--environment-create \
--environment ci \
--environment-project ventes \
--environment-purpose=Testing \
--environment-config-files=/builds/ventes/config/ci-config.jsonL’option --environment-purpose accepte des valeurs telles que Development, Testing ou Production : elle documente l’intention de l’environnement, ce qui devient précieux quand plusieurs environnements coexistent. Si votre projet range métadonnées, jeux de données ou tests ailleurs que dans les emplacements par défaut, les options --project-metadata-base, --project-datasets-base et --project-unit-tests-base permettent de le préciser à la création.
Un détail qui fait gagner du temps : positionnez la variable d’environnement HOP_CONFIG_FOLDER vers un dossier hors de l’installation Hop. La configuration produite par hop-conf survit alors à un changement de version du client, et vous pouvez la mettre en cache entre deux builds. hop-conf --projects-list et --environments-list sont utiles pour vérifier, dans les journaux du build, que l’enregistrement s’est bien passé.
3. Exécuter les tests unitaires sans interface graphique
C’est le point qui bloque la plupart des équipes : les tests unitaires de pipelines se définissent dans Hop GUI, on les croit donc liés à l’interface. Ce n’est pas le cas. Hop fournit une action de workflow Run pipeline unit tests, dont la documentation précise qu’elle « peut exécuter tous les tests définis d’un certain type » et que « l’action réussit si tous les tests s’exécutent sans erreur ».
La démarche est donc la suivante : créez un workflow dédié, par exemple tests/run-all-tests.hwf, contenant cette seule action. Dans sa configuration, le champ Test names attend la liste des tests à jouer, et le bouton Get test names récupère les tests disponibles dans le projet courant, ce qui évite de les saisir à la main. Ce workflow devient votre point d’entrée de test, versionné comme le reste.
sh hop-run.sh \
--project ventes \
--environment ci \
--file tests/run-all-tests.hwf \
--runconfig local \
--level Basic \
--logfile /builds/reports/tests.logIl existe aussi un transform Execute unit tests, qui permet d’exécuter les tests depuis un pipeline et d’en récupérer les résultats sous forme de lignes : pratique si vous souhaitez produire un rapport plutôt qu’un simple verdict.
4. Faire échouer le build au bon moment
Une chaîne CI/CD n’a de valeur que si elle sait dire non. hop-run renvoie des codes de sortie explicites, qu’il suffit de laisser remonter :
| Code | Signification documentée |
| 0 | Aucune erreur, tout s’est déroulé parfaitement. |
| 1 | Une erreur est survenue lors de l’exécution du workflow ou du pipeline. |
| 2 | Une erreur générale a fait échouer Hop Run complètement. |
| 9 | Une erreur d’analyse des paramètres fournis. |
Un test unitaire en échec fait échouer l’action, donc le workflow, donc hop-run, qui sort en 1. Aucune configuration particulière n’est nécessaire : n’écrasez simplement pas le code de retour dans votre script. Le code 9 mérite une attention particulière, car il signale une erreur de syntaxe dans vos paramètres, pas un problème de données. Pendant la mise au point, l’option --printoptions affiche les options réellement utilisées par Hop Run, ce qui lève rapidement les doutes sur une variable mal transmise.
Voici l’enchaînement complet, exprimé ici pour GitHub Actions mais transposable tel quel ailleurs :
jobs:
hop-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
with:
distribution: temurin
java-version: '21'
- name: Installer le client Hop
run: |
curl -sSL -o hop-client.zip \
"https://www.apache.org/dyn/closer.lua/hop/2.19.0/apache-hop-client-2.19.0.zip?action=download"
unzip -q hop-client.zip
- name: Enregistrer projet et environnement
run: |
cd hop
sh hop-conf.sh --project-create --project ventes \
--project-home "$GITHUB_WORKSPACE"
sh hop-conf.sh --environment-create --environment ci \
--environment-project ventes --environment-purpose=Testing \
--environment-config-files="$GITHUB_WORKSPACE/config/ci-config.json"
- name: Jouer les tests unitaires
env:
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
run: |
cd hop
sh hop-run.sh --project ventes --environment ci \
--file tests/run-all-tests.hwf --runconfig local \
--parameters PARAM_DB_PASSWORD=$DB_PASSWORDLes options --parameters et --system-properties sont vos deux canaux d’injection : la première pour les paramètres déclarés dans vos pipelines, la seconde pour des propriétés système sous forme de paires CLÉ=VALEUR séparées par des virgules.
5. La variante conteneurisée
Si votre agent de build ne doit rien installer, l’image officielle apache/hop, publiée par le projet, fait le même travail. Elle crée projet et environnement au démarrage à partir de variables d’environnement, puis exécute le fichier demandé et s’arrête.
docker run --rm \
--env HOP_PROJECT_NAME=ventes \
--env HOP_PROJECT_FOLDER=/files \
--env HOP_ENVIRONMENT_NAME=ci \
--env HOP_ENVIRONMENT_CONFIG_FILE_NAME_PATHS=/files/config/ci-config.json \
--env HOP_FILE_PATH='${PROJECT_HOME}/tests/run-all-tests.hwf' \
--env HOP_RUN_CONFIG=local \
--env HOP_LOG_LEVEL=Basic \
-v "$PWD":/files \
apache/hop:2.19.0Le code de sortie du conteneur est celui de Hop Run : la logique d’échec du build reste inchangée. Deux variables méritent d’être connues : HOP_RUN_PARAMETERS pour transmettre les paramètres, et HOP_SHARED_JDBC_FOLDERS pour monter vos pilotes JDBC, que l’image ne peut pas embarquer pour des raisons de licence.
6. Et le déploiement ?
Une fois les tests verts, le déploiement d’un projet Hop consiste à mettre à disposition le même contenu de dépôt sur la cible, avec un environnement différent. C’est tout l’intérêt du modèle projet / environnement : le même commit produit le comportement de recette ou de production selon la valeur de --environment. Concrètement, votre étape de déploiement se réduit à synchroniser les fichiers vers la machine d’exécution, ou à publier une image contenant le projet, puis à laisser Hop Server ou votre ordonnanceur appeler hop-run avec l’environnement de production.
Ce que vous y gagnez
En une poignée de commandes, vous obtenez trois garanties concrètes : aucune modification de pipeline ne peut atteindre la production sans que les tests unitaires aient été rejoués, la version déployée est identifiée par un commit, et l’installation Hop utilisée par la chaîne est reconstruite de zéro à chaque build, donc reproductible. La bascule vers un nouvel environnement ne demande plus qu’un changement d’argument, et le fameux « ça marchait sur mon poste » n’a plus de prise.
Pour aller plus loin
- Hop Run : options de ligne de commande et codes de sortie
- Hop Conf : gestion des projets et des environnements
- Tests unitaires de pipelines
- Action Run pipeline unit tests
- Prérequis, installation et variables d’environnement HOP_*
- Conteneur Docker apache/hop et ses variables
L’industrialisation des projets Hop, de la gestion d’erreurs jusqu’à l’intégration continue, constitue le cœur de notre formation Apache Hop — Perfectionnement et industrialisation, que nous animons volontiers sur vos propres projets.