-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
Jenkins => 2.89.3
Pipeline Input Step => 2.8
Pipeline Milestone Step => 1.3.1
Problem
When:
- using a milestone before an input,
- and one (or more) of the build is waiting for user input,
- and a failure in another build happens,
- the builds waiting for input will abort older jobs.
Duplication Steps
- Create a job with the following code:
node { milestone label: 'test1', ordinal: 1 input 'test' sh 'exit 1' } - Trigger two builds.
- Approve the newest job (#2) to continue.
Current behavior
The newer job (#2) will fail, the older job (#1) will be aborted and display Superseded by <jobname>#<build_num> which is pretty confusing.
Expected behavior
The newer job (#2) will fail, while the older job (#1) will wait for confirmation.
Workaround
Removing all milestone before the input seems to solve the issue.
node {
input 'test'
sh 'exit 1'
milestone label: 'test1', ordinal: 1
}
Might be tangeantially related to JENKINS-41604
[JENKINS-49447] Using a milestone before an input will abort older build if there is a failure while the older build wait for a user input
Jean-Martin Archer
created issue -
Jean-Martin Archer
made changes -
| Summary | Original: sing a milestone before an input will abort older build if there is a failure while the older build wait for a user input | New: Using a milestone before an input will abort older build if there is a failure while the older build wait for a user input |
Jean-Martin Archer
made changes -
| Description |
Original:
h2. Problem When: # using a milestone before an input, # one (or more) of the build is waiting for user input, # and a failure in another build happens, # the builds waiting for input will abort older jobs. h2. Duplication Steps # Create a job with the following code: \{code:title=|language=none|collapse=false}node \{ milestone label: 'test1', ordinal: 1 input 'test' sh 'exit 1' } \{code} # Trigger two builds. # Approve the newest job (#2) to continue. h2. Current behavior The newer job (#2) will fail, the older job (#1) will be aborted and display \{\{Superseded by <jobname>#<build_num>}} h2. Expected behavior The newer job (#2) will fail, while the older job (#1) will wait for confirmation. h2. Workaround Removing all milestone before the input seems to solve the issue. \{code:title=|language=none|collapse=false}node \{ input 'test' sh 'exit 1' milestone label: 'test1', ordinal: 1 } \{code} Might be tangeantially related to JENKINS-41604 |
New:
h2. Problem When: # using a milestone before an input, # one (or more) of the build is waiting for user input, # and a failure in another build happens, # the builds waiting for input will abort older jobs. h2. Duplication Steps # Create a job with the following code: {code:java} node { milestone label: 'test1', ordinal: 1 input 'test' sh 'exit 1' } {code} # Trigger two builds. # Approve the newest job (#2) to continue. h2. Current behavior The newer job (#2) will fail, the older job (#1) will be aborted and display {{Superseded by <jobname>#<build_num>}} which is pretty confusing. h2. Expected behavior The newer job (#2) will fail, while the older job (#1) will wait for confirmation. h2. Workaround Removing all milestone before the input seems to solve the issue. {code} node { input 'test' sh 'exit 1' milestone label: 'test1', ordinal: 1 } {code} Might be tangeantially related to JENKINS-41604 |
Jean-Martin Archer
made changes -
| Description |
Original:
h2. Problem When: # using a milestone before an input, # one (or more) of the build is waiting for user input, # and a failure in another build happens, # the builds waiting for input will abort older jobs. h2. Duplication Steps # Create a job with the following code: {code:java} node { milestone label: 'test1', ordinal: 1 input 'test' sh 'exit 1' } {code} # Trigger two builds. # Approve the newest job (#2) to continue. h2. Current behavior The newer job (#2) will fail, the older job (#1) will be aborted and display {{Superseded by <jobname>#<build_num>}} which is pretty confusing. h2. Expected behavior The newer job (#2) will fail, while the older job (#1) will wait for confirmation. h2. Workaround Removing all milestone before the input seems to solve the issue. {code} node { input 'test' sh 'exit 1' milestone label: 'test1', ordinal: 1 } {code} Might be tangeantially related to JENKINS-41604 |
New:
h2. Problem When: # using a milestone before an input, # and one (or more) of the build is waiting for user input, # and a failure in another build happens, # the builds waiting for input will abort older jobs. h2. Duplication Steps # Create a job with the following code: {code:java} node { milestone label: 'test1', ordinal: 1 input 'test' sh 'exit 1' } {code} # Trigger two builds. # Approve the newest job (#2) to continue. h2. Current behavior The newer job (#2) will fail, the older job (#1) will be aborted and display {{Superseded by <jobname>#<build_num>}} which is pretty confusing. h2. Expected behavior The newer job (#2) will fail, while the older job (#1) will wait for confirmation. h2. Workaround Removing all milestone before the input seems to solve the issue. {code} node { input 'test' sh 'exit 1' milestone label: 'test1', ordinal: 1 } {code} Might be tangeantially related to JENKINS-41604 |
| Priority | Original: Minor [ 4 ] | New: Critical [ 2 ] |
Changed to critically as waiting jobs for deployment are cancelled and in combination with buildDiscarder are removed after this.
Here an example of a declarative Pipeline, where 2 input exists and therefore the workaround does not work:
pipeline {
agent any
stages {
stage ("Ask 1") {
steps {
input message: 'Ask 1'
milestone ordinal: 1
sh '''
echo $BUILD_NUMBER
if [ `echo "${BUILD_NUMBER} % 3" | bc` -eq 0 ]
then
exit 1
fi'''
}
}
stage ("Ask 2") {
steps {
input message: 'Ask 2'
milestone ordinal: 2
}
}
}
}
test case 1 - breaking job kills wainting jobs before:
- start build 1, answer input "Ask 1" with proceed
- start build 2, answer input "Ask 1" with proceed
- start build 3, answer input "Ask 1" with proceed
- > build with build number, which can divided by 3 breaks by default and cancels all waiting job before
test case 2 - cancel job kills wainting jobs before:
- start build 1, answer input "Ask 1" with proceed
- start build 2, answer input "Ask 1" with proceed, answer input "Ask 2" with cancel or cancel the build via the executor cancel button
- > canceled build cancels all waiting job before
The mentioned workaround unfortunatly means running in another bug: https://issues.jenkins-ci.org/browse/JENKINS-46097