-
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 ] |