Beaucoup d’équipes ont déjà un Jenkins pour l’intégration continue. Plutôt que d’ajouter un ordonnanceur de plus, on peut lui confier l’exécution planifiée des traitements Apache Hop : déclenchement à heure fixe, historique, logs, alertes en cas d’échec. Voici comment le faire proprement.
Le principe : Jenkins déclenche, Hop exécute
Jenkins ne connaît rien aux données. Il lance Hop Run (hop-run.sh), l’exécuteur en ligne de commande d’Apache Hop, sur un agent où Hop est installé (ou dans un conteneur). Hop Run renvoie un code de sortie non nul en cas d’erreur : Jenkins marque alors le build en échec et peut prévenir l’équipe.
On garde ainsi une répartition claire :
- Hop porte la logique de données : pipelines et workflows versionnés dans Git.
- Jenkins porte le quand et le comment : planification, paramètres, secrets, historique et notifications.
Préparer l’agent
Sur l’agent Jenkins, installez Hop et déclarez une fois le projet et son environnement avec hop-conf.sh (ou laissez Hop Run les créer via ses variables). Le dépôt Git contient le projet Hop ; les fichiers d’environnement ne contiennent aucun mot de passe, seulement des références comme ${DB_PASSWORD}.
Un Jenkinsfile complet
pipeline {
agent { label 'hop' }
triggers { cron('H 2 * * *') } // chaque nuit vers 2 h
parameters {
string(name: 'DATE_TRAITEMENT', defaultValue: '',
description: 'Vide = date du jour')
}
options {
timeout(time: 1, unit: 'HOURS')
disableConcurrentBuilds()
buildDiscarder(logRotator(numToKeepStr: '60'))
}
environment {
DB_PASSWORD = credentials('dwh-password') // secret Jenkins
}
stages {
stage('Récupérer le projet') {
steps { checkout scm }
}
stage('Charger les commandes') {
steps {
sh """
/opt/hop/hop-run.sh \\
--project=orders \\
--environment=prod \\
--file=workflows/load-orders.hwf \\
--runconfig=local \\
--level=Basic \\
--parameters=DATE_TRAITEMENT=${params.DATE_TRAITEMENT}
"""
}
}
}
post {
failure {
mail to: 'data@exemple.fr',
subject: "Échec ${env.JOB_NAME} #${env.BUILD_NUMBER}",
body: "Voir les logs : ${env.BUILD_URL}console"
}
}
}
Quelques points à noter :
H 2 * * *laisse Jenkins répartir l’heure exacte pour éviter que tous les jobs démarrent à la même minute.disableConcurrentBuilds()empêche deux chargements de se chevaucher si l’un d’eux traîne.- Le secret
dwh-passwordest stocké dans Jenkins et injecté comme variable d’environnement, que Hop lit via${DB_PASSWORD}. Il est masqué dans les logs. - Le paramètre
DATE_TRAITEMENTpermet de relancer un jour précis depuis l’interface de Jenkins, sans toucher au code.
Variante : exécuter Hop dans un conteneur
Si vos agents Jenkins savent lancer Docker, l’image officielle apache/hop évite d’installer Hop sur chaque agent. Les options de Hop Run passent alors par des variables HOP_*. Le détail est dans notre guide Exécuter Apache Hop dans Docker.
Enchaîner plusieurs traitements
Deux options, à ne pas mélanger :
- Un workflow Hop qui enchaîne les pipelines, lancé par un seul stage Jenkins. Idéal quand les étapes forment un tout cohérent (voir Workflows Apache Hop).
- Plusieurs stages Jenkins, un par traitement. Utile quand on veut relancer une étape isolément ou exécuter des branches en parallèle avec
parallel.
Dans les deux cas, évitez de coder les mêmes dépendances à deux endroits.
Tester avant de déployer
Le même Jenkins peut exécuter les tests unitaires de pipelines Hop à chaque commit, avant que la version ne parte en production. C’est la base d’une chaîne CI/CD pour Apache Hop.
Aller plus loin
La formation Jenkins — Fondamentaux prend exactement ce fil rouge : en une journée et seize travaux pratiques, on installe Jenkins, on crée jobs et pipelines déclaratifs, on gère secrets et sauvegardes, et on orchestre des flux Apache Hop. Pour industrialiser ensuite (Shared Libraries, agents Docker ou Kubernetes, configuration as code), voir Jenkins — Pipelines avancés. Toutes nos formations Jenkins sont sur la page Formations Jenkins.