Après avoir parcouru la documentation pipeline et Jenkinsfile , je suis un peu confus sur la façon de créer une étape -> Production pipeline.
Une solution consiste à utiliser l'étape input
comme
node() {
stage 'Build to Stage'
sh '# ...'
input 'Deploy to Production'
stage 'Build to Production'
sh '# ...'
}
Cela semble un peu maladroit, car cela bloquera tout le temps un exécuteur jusqu'à ce que vous souhaitiez le déployer en production. Jenkins propose-t-il un autre moyen de se déployer en production?.
EDIT (oct 2016): Voir mon autre réponse "Utiliser un jalon et un verrou" ci-dessous, qui inclut les fonctionnalités récemment introduites.
timeout
StepEn première option, vous pouvez envelopper votre étape sh
dans une étape timeout
.
node() {
stage 'Build to Stage' {
sh '# ...'
}
stage 'Promotion' {
timeout(time: 1, unit: 'HOURS') {
input 'Deploy to Production?'
}
}
stage 'Deploy to Production' {
sh '# ...'
}
}
Cela arrête la construction après le délai d'attente.
input
Pas à pas vers l'exécuteur poids moucheUne autre option consiste à ne pas affecter un exécuteur poids lourd pour l'étape input
. Vous pouvez le faire en utilisant l'étape input
en dehors du bloc node
, comme ceci:
stage 'Build to Stage' {
node {
sh "echo building"
stash 'complete-workspace'
}
}
stage 'Promotion' {
input 'Deploy to Production?'
}
stage 'Deploy to Production' {
node {
unstash 'complete-workspace'
sh "echo deploying"
}
}
Cette est était probablement le moyen le plus élégant, mais peut toujours être combiné avec l'étape timeout
.
EDIT: Comme l'a souligné @amuniz, vous devez masquer/extraire le contenu de l'espace de travail, car des nœuds différents peuvent être alloués à des répertoires d'espace de travail pour les deux étapes node
.
Compte tenu des avancées récentes des pipelines Jenkins, la meilleure solution serait probablement la suivante (source: jenkins.io/blog ):
milestone
et lock
lock
(du plugin lockable-resources ) permet de verrouiller certaines ressources spécifiées de manière à ce qu’une seule exécution de pipeline puisse entrer simultanément dans cette étape (vous vous ne voulez pas exécuter deux déploiements simultanément, n'est-ce pas?)milestone
(du plugin pipeline-milestone-step ) annulera toute exécution antérieure du pipeline, si une validation plus récente a déjà atteint le jalon (vous ne voulez pas laisser un commit plus ancien accrocher plus longtemps dans CI, écrasez le déploiement d'un commit plus récent, n'est-ce pas?).stage('Deploy') {
input "Deploy?"
milestone()
lock('Deployment') {
node {
echo "Deploying"
}
}
}
L'étape de déploiement ne limite pas la concurrence, mais nécessite une entrée manuelle de la part d'un utilisateur. Plusieurs générations peuvent atteindre cette étape en attendant une entrée. Lorsqu'un utilisateur promeut une construction spécifique, toutes les générations précédentes sont abandonnées, ce qui garantit que le dernier code est toujours déployé.
Je recommande de lire toute l'histoire , qui contient d'autres informations utiles.
Les crédits vont à @ amuniz , qui assure la maintenance de ces plugins.
Vous devez utiliser l’étape d’entrée en dehors de tout bloc de noeud pour qu’il ne contienne aucun exécutant:
stage 'Build'
node('build-node') {
sh 'call you build tool'
stash includes: 'target/my-output-artifact.whatever', name: 'built'
}
input 'Continue to deploy stage?'
stage 'Deploy'
node('deploy-node') {
unstash 'built'
sh 'scp target/my-output-artifact.whatever user@deploy-server:/deploy'
}
Et vous pouvez verrouiller la phase de déploiement si vous ne voulez qu'un seul déploiement à la fois:
lock ('deploy-server') {
stage 'Deploy'
node('deploy-node') {
unstash 'built'
sh 'scp target/my-output-artifact.whatever user@deploy-server:/deploy'
}
}
Notez que la partie clé ici est l’étape stash
que vous pouvez déplacer artefacts d’un nœud à un autre (vous pouvez partager le même nœud pour les deux actions mais l’espace de travail n’est pas autorisé à intacte entre les deux appels de nœud, en particulier si attendre un certain temps sur input
).