jenkinsci / jenkinsci/workflow-basic-steps-plugin

[JENKINS-56766] Allow preserved stashes to be used in new run of the job

Abierto
#486 1 comentario 0 reacciones 0 asignados Ver en GitHub
component:workflow-basic-steps-plugin imported-jira-issue priority:minor resolution:unresolved
Lenguaje dominante
Java
Estrellas
73
Forks
129
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

Ref.: https://jenkins.io/doc/book/pipeline/running-pipelines/#preserving-stashes-for-use-with-restarted-stages

Currently we can request that a stash be kept after a job finishes, even for more than one job (why? it is not clear from the text above how this would be useful. Multiple restarts perhaps?). But it is only available if we restart a stage of a job (so I guess it must have failed). At least is what the above text seems to imply and some empirical data confirms.

As we are storing the stash tar balls anyway, why not make them available for the next job that starts regularly (as opposed to with a restart)? That way we could store some data to be tested on the next run and make a decision based on it.

Possible use cases would be to store something like the last commitId tested so you don't run the tests again for the same code and any other things about the last run that would be useful for the next run.

E.g.:

pipeline {

agent {
node {
label 'centos'
}
}
options {
preserveStashes(buildCount: 5)
}
environment {
CHANGED = 'False'
}
stages {
stage('Check for changes'){
agent {
node {
label 'rhel'
}
}
steps {
script {
def cmd = "git ls-remote https://xxx.yyyy.zzz.com/mycode.git master | awk '{print \$1}' | tee last-image-build.txt.new"
echo "cmd: ${cmd}"
def newcommitid = sh (returnStdout: true, script: "${cmd}")
echo "newcommitid: ${newcommitid}"
try {
unstash 'last-image-build'
} catch (Exception e) {
echo "last-image-build stash not found, assume changed"
CHANGED = 'True'
}
if (fileExists('last-image-build.txt')) {
def oldcommitid = readFile 'last-image-build.txt'
echo "oldcommitid: ${oldcommitid}"
if (oldcommitid != newcommitid) {
CHANGED = 'True'
echo "CHANGED new value: ${CHANGED}"
}
}
sh 'mv -f last-image-build.txt.new last-image-build.txt'
stash name: 'last-image-build', includes: 'last-image-build.txt', allowEmpty:true
echo "CHANGED: ${CHANGED}"
}
}
}
stage('Build only if changed'){
when {
expression { environment name: 'CHANGED', value: 'True' }
}
steps{
echo "BUILDING"
}
}
}
}

 

 

---
Originally reported by fnasser, imported from: Allow preserved stashes to be used in new run of the job


  • status: Open
  • priority: Minor
  • component(s): workflow-basic-steps-plugin
  • resolution: Unresolved
  • votes: 1
  • watchers: 3
  • imported: 20251215-220547

Raw content of original issue

Ref.: https://jenkins.io/doc/book/pipeline/running-pipelines/#preserving-stashes-for-use-with-restarted-stages

Currently we can request that a stash be kept after a job finishes, even for more than one job (why? it is not clear from the text above how this would be useful. Multiple restarts perhaps?). But it is only available if we restart a stage of a job (so I guess it must have failed). At least is what the above text seems to imply and some empirical data confirms.

As we are storing the stash tar balls anyway, why not make them available for the next job that starts regularly (as opposed to with a restart)? That way we could store some data to be tested on the next run and make a decision based on it.

Possible use cases would be to store something like the last commitId tested so you don't run the tests again for the same code and any other things about the last run that would be useful for the next run.

E.g.:



pipeline {

agent {
node {
label 'centos'
}
}
options {
preserveStashes(buildCount: 5)
}
environment {
CHANGED = 'False'
}
stages {
stage('Check for changes'){
agent {
node {
label 'rhel'
}
}
steps {
script {
def cmd = "git ls-remote https://xxx.yyyy.zzz.com/mycode.git master | awk '{print \$1}' | tee last-image-build.txt.new"
echo "cmd: ${cmd}"
def newcommitid = sh (returnStdout: true, script: "${cmd}")
echo "newcommitid: ${newcommitid}"
try {
unstash 'last-image-build'
} catch (Exception e) {
echo "last-image-build stash not found, assume changed"
CHANGED = 'True'
}
if (fileExists('last-image-build.txt')) {
def oldcommitid = readFile 'last-image-build.txt'
echo "oldcommitid: ${oldcommitid}"
if (oldcommitid != newcommitid) {
CHANGED = 'True'
echo "CHANGED new value: ${CHANGED}"
}
}
sh 'mv -f last-image-build.txt.new last-image-build.txt'
stash name: 'last-image-build', includes: 'last-image-build.txt', allowEmpty:true
echo "CHANGED: ${CHANGED}"
}
}
}
stage('Build only if changed'){
when {
expression { environment name: 'CHANGED', value: 'True' }
}
steps{
echo "BUILDING"
}
}
}
}


 

 

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

Comienza con la documentación enlazada de Jenkins sobre la conservación de stashes para stages reiniciados y el ejemplo que usa preserveStashes y unstash. Aclara cómo se debe seleccionar un stash conservado para una ejecución nueva normal, incluido el comportamiento de retención y de nomenclatura. Se considerará terminado cuando una nueva ejecución del job pueda usar los datos conservados y el comportamiento esté documentado y verificado mediante las pruebas adecuadas del plugin.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
java
Área
ci-cd
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
30/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.