jenkinsci / jenkinsci/workflow-basic-steps-plugin

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

Offen
#486 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
component:workflow-basic-steps-plugin imported-jira-issue priority:minor resolution:unresolved
Vorherrschende Sprache
Java
Sterne
73
Forks
129
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

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"
}
}
}
}


 

 

Beitragsleitfaden

Beitragsleitfaden öffnen

Rechercherichtung

Start with the linked Jenkins documentation on preserving stashes for restarted stages and the example using preserveStashes and unstash. Clarify how a preserved stash should be selected for a regular new run, including retention and naming behavior. Done means a new job run can use the preserved data, with the behavior documented and verified by appropriate plugin tests.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
java
Bereich
ci-cd
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
30/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.