[JIRA] (JENKINS-38993) Deterministic order of build condition block execution in Declarative

1 view
Skip to first unread message

andrew.bayer@gmail.com (JIRA)

unread,
Oct 14, 2016, 10:34:06 AM10/14/16
to jenkinsc...@googlegroups.com
Andrew Bayer created an issue
 
Jenkins / Improvement JENKINS-38993
Deterministic order of build condition block execution in Declarative
Issue Type: Improvement Improvement
Assignee: Andrew Bayer
Components: pipeline-model-definition-plugin
Created: 2016/Oct/14 2:33 PM
Priority: Minor Minor
Reporter: Andrew Bayer

The build condition responders (currently postBuild and notifications, soon to be post within a stage) currently execute in the order they're specified in the Jenkinsfile. That should be changed to a deterministic order that'll be the same every time, and that order should be well documented and exposed in the logs.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

andrew.bayer@gmail.com (JIRA)

unread,
Oct 19, 2016, 7:41:03 AM10/19/16
to jenkinsc...@googlegroups.com

stephen.alan.connolly@gmail.com (JIRA)

unread,
Oct 19, 2016, 8:30:01 AM10/19/16
to jenkinsc...@googlegroups.com

OK, this may be somewhat controversial...

The only reason for a "success" condition is if that condition runs after "always"... if it were to run before "always" then we could just replace it with steps / stage at the end of the scope that the conditions apply to.

Thus, as we are not allowing repeats, we have to start with the most general condition and then proceed to the most specific.

Where conditions of the same level of specificity are mutually exclusive, run the defined order should be alphanumeric sort

1. Always - the most generic condition
2. Changed - the second most generic condition, won't match every build, but can potentially match builds of any status
3. The group of mutually exclusive conditions

  • Aborted
  • Failure
  • Success
  • Unstable

stephen.alan.connolly@gmail.com (JIRA)

unread,
Oct 19, 2016, 8:32:01 AM10/19/16
to jenkinsc...@googlegroups.com
Stephen Connolly edited a comment on Improvement JENKINS-38993
OK, this may be somewhat controversial...

The only reason for a "success" condition is if that condition runs after "always"... if it were to run before "always" then we could just replace it with steps / stage at the end of the scope that the conditions apply to.

Thus, as we are not allowing repeats, we have to start with the most general condition and then proceed to the most specific.

Where conditions of the same level of specificity are mutually exclusive, run the defined order should be alphanumeric sort (not that the defined order impacts anything as they are all mutually exclusive, so only one will ever run)

1. Always - the most generic condition
2. Changed - the second most generic condition, won't match every build, but can potentially match builds of any status
3. The group of mutually exclusive conditions
* Aborted
* Failure
* Success
* Unstable

This also helps with failures in more generic conditions, as the Failure / Aborted conditions will be in the final set

andrew.bayer@gmail.com (JIRA)

unread,
Oct 20, 2016, 5:39:01 AM10/20/16
to jenkinsc...@googlegroups.com

Sounds good to me. Implementing now. =)

andrew.bayer@gmail.com (JIRA)

unread,
Oct 20, 2016, 6:53:03 AM10/20/16
to jenkinsc...@googlegroups.com
Andrew Bayer started work on Improvement JENKINS-38993
 
Change By: Andrew Bayer
Status: Open In Progress

andrew.bayer@gmail.com (JIRA)

unread,
Oct 20, 2016, 6:53:03 AM10/20/16
to jenkinsc...@googlegroups.com
Change By: Andrew Bayer
Status: In Progress Review

andrew.bayer@gmail.com (JIRA)

unread,
Oct 20, 2016, 6:54:01 AM10/20/16
to jenkinsc...@googlegroups.com

andrew.bayer@gmail.com (JIRA)

unread,
Oct 24, 2016, 9:55:02 AM10/24/16
to jenkinsc...@googlegroups.com
 

Merged, will be released in 0.5.
Change By: Andrew Bayer
Status: In Review Resolved
Resolution: Fixed

scm_issue_link@java.net (JIRA)

unread,
Oct 24, 2016, 9:55:03 AM10/24/16
to jenkinsc...@googlegroups.com
SCM/JIRA link daemon commented on Improvement JENKINS-38993
 
Re: Deterministic order of build condition block execution in Declarative

Code changed in jenkins
User: Andrew Bayer
Path:
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/AbstractBuildConditionResponder.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Aborted.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Always.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Changed.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Failure.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Success.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Unstable.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/validator/ModelValidatorImpl.groovy
pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/model/BuildCondition.java
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/BuildConditionResponderTest.java
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/ValidatorTest.java
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/endpoints/ModelConverterActionTest.java
pipeline-model-definition/src/test/resources/buildConditionOrdering.groovy
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/57afb524540ed8be1d0eda9969209f9791d38c5a
Log:
[FIXED JENKINS-38993] Add deterministic ordering of conditions.

Ordering is:

  • Always
  • Changed
  • Aborted/Failure/Success/Unstable

This is all done via ordinals.

scm_issue_link@java.net (JIRA)

unread,
Oct 24, 2016, 9:57:01 AM10/24/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Andrew Bayer
Path:
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/AbstractBuildConditionResponder.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Aborted.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Always.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Changed.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Failure.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Success.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Unstable.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/validator/ModelValidatorImpl.groovy
pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/model/BuildCondition.java
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/BuildConditionResponderTest.java
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/ValidatorTest.java
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/endpoints/ModelConverterActionTest.java
pipeline-model-definition/src/test/resources/buildConditionOrdering.groovy

[FIXED JENKINS-38993] Add deterministic ordering of conditions.

josephp90@gmail.com (JIRA)

unread,
Mar 27, 2017, 8:11:01 AM3/27/17
to jenkinsc...@googlegroups.com

Andrew Bayer

The deterministic order is irritating to deal with when having to do something like this because Macs that have static workspaces and working with multiple slaves.
I would prefer to have it follow my order or actually lower the always to something below success and failure...
I could do the success as part of the stages but success provide me with a logical block to put certain events into the proper block

            post {
                failure {
                    archiveArtifacts 'fastlane/logs/**/*.log'
                }
                success {
                   script { 
                       if (env.BRANCH_NAME == 'development') { 
                           stash name: 'debug-ipa', includes: "output/*.ipa" 
                       }
                    }
                }
                always {
                    delete()
                }
            }
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

josephp90@gmail.com (JIRA)

unread,
Mar 27, 2017, 8:15:03 AM3/27/17
to jenkinsc...@googlegroups.com
Joseph Petersen edited a comment on Improvement JENKINS-38993
[~abayer]

The deterministic order is irritating to deal with when having to do something like this because Macs that have static workspaces and working with multiple slaves nodes .

I would prefer to have it follow my order or actually lower the always to something below success and failure...
I could do the success as part of the stages but success provide me with a logical block to put certain events into the proper block
{code:java}

            post {
                failure {
                    archiveArtifacts 'fastlane/logs/**/*.log'
                }
                success {
                   script {
                     if (env.BRANCH_NAME == 'development') {
                     stash name: 'debug-ipa', includes: "output/*.ipa"
                     }
                    }
                }
                always {
                    delete()
                }
            }
{code}

bitwiseman@gmail.com (JIRA)

unread,
Oct 22, 2019, 11:25:51 PM10/22/19
to jenkinsc...@googlegroups.com
Liam Newman closed an issue as Fixed
 

Bulk closing resolved issues.

Change By: Liam Newman
Status: Resolved Closed
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages