-
Story
-
Resolution: Fixed
-
Minor
-
None
-
Pipeline Config 0.1
-
Powered by SuggestiMate
It'd be handy to be able to have notifications specified for individual stages as well as for the whole build.
- causes
-
JENKINS-57801 Execution of post stage block is based on pipeline status, not stage result which docs says it should
-
- Open
-
[JENKINS-37792] Pipeline Config: Notifications per stage
I agree about the camelCase of postBuild but figured it only bothered me so I let it pass.
I'm thinking about it from a user's point of view stephenconnolly not how it is implemented in the backend. I have stages that contain steps. Alternating steps with success, failure, always is confusing and no different than wrapping steps in try...catch blocks by hand.
We should only allow a single steps block inside a stage. These steps make up the function of the stage and treat them as a whole unit. If one of these steps fails then the stage fails. Parsing that down into smaller units gets more complex and adds little value. If you want to break it down to further pieces then add a new stage.
Maybe success is superfluous in implementation but would it make sense from a user point of view? What are the use cases for success?
- cleaning up the workspace?
- stashing files?
- notifications?
If we kill postBuild what happens to this functionality? IMO, the main use cases for postBuild (despite the name) is:
- As a user I don't want to configure anything at the stage level but want to have notifications and/or postBuild globally
> If we kill postBuild what happens to this functionality?
So the notifications would still exist. And the other uses of postBuild are subsumbed by a lastly block at the end of all the stages (or we use a special syntax on stage to indicate that the stage is always run in order to remove the discontinuity
I still don't like the idea of having a special notifications block at the top level but a separate method for notifications inside a stage. This creates a poor user experience IMO.
well, obviously "lastly" is literally the worst name ever in the history of bad names. Well maybe after "vietnam4j".
postBuild terminology is used elsewhere (outside of jenkins) and is fairly self explanatory (but it isn't as nice as the pluralised "notifications"). I view it as an abbrevation of "post build actions" - plural. There is probably a single german word for that The camel case isn't optimal, yeah.
Whatever the keyword names/reserved names are, the ideal is that as much as possible, things that can be done globally could be done in a stage, which are then scoped to it. unfortunately the name "post build" doesn't quite work. Notifications as a name works...
I do agree that having the same events as notifications/postBuild in stage is nice (often there is a need to always cleanup, regardless of outcome).
Given this ticket is is about notifications - I think it is ok to say that notifications happening in the node that the stage happens with is ok (doesn't make a lot of difference to the user).
If we want to talk about general events, naming, globally or stages, we should setup a time to explore it on a hangout, as there is lots we could cover, and there are good ideas here.
Code changed in jenkins
User: Robert Sandell
Path:
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/ast/ModelASTBuildConditionsContainer.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/ast/ModelASTNotifications.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/ast/ModelASTPostBuild.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/ast/ModelASTPostStage.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/ast/ModelASTStage.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/PostStage.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Root.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Stage.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/JSONParser.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/ModelParser.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/validator/ModelValidator.groovy
src/main/resources/ast-schema.json
src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/PostStageTest.java
src/test/resources/postStage/failingNotifications.groovy
src/test/resources/postStage/globalAndLocalAlways.groovy
src/test/resources/postStage/localAll.groovy
src/test/resources/postStage/localAlways.groovy
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/061eebc2c0af2fc92420ccc746c2f8349727a34e
Log:
JENKINS-37792 Per stage post build steps
Code changed in jenkins
User: Robert Sandell
Path:
src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/PostStageTest.java
src/test/resources/postStage/failingNotifications.groovy
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/b9c1124dda30d9968fec6f99627e3fcf1a44caae
Log:
JENKINS-37792 Test when a notification fails
Code changed in jenkins
User: Andrew Bayer
Path:
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/ast/ModelASTBuildConditionsContainer.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/ast/ModelASTNotifications.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/ast/ModelASTPostBuild.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/ast/ModelASTPostStage.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/ast/ModelASTStage.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/PostStage.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Root.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Stage.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/JSONParser.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/ModelParser.groovy
src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/validator/ModelValidator.groovy
src/main/resources/ast-schema.json
src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/AbstractModelDefTest.java
src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/PostStageTest.java
src/test/resources/postStage/failingNotifications.groovy
src/test/resources/postStage/globalAndLocalAlways.groovy
src/test/resources/postStage/localAll.groovy
src/test/resources/postStage/localAlways.groovy
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/9517f02825eaa52f20dde2e73c70eed2a8260a59
Log:
Merge pull request #30 from jenkinsci/JENKINS-37792
JENKINS-37792 Per stage post build steps
Compare: https://github.com/jenkinsci/pipeline-model-definition-plugin/compare/b7a3ec68779e...9517f02825ea
Code changed in jenkins
User: Robert Sandell
Path:
SYNTAX.md
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/71c3d60ee486e48757bbd76315dc69a9e0418775
Log:
Update SYNTAX.md
Noting changes introduced in JENKINS-37792, JENKINS-37781 and JENKINS-37778
Also fixed the script example and marked the code sections as groovy
so that GitHub hopefully can color the code a bit more nicely.
hrmpw so what is the difference between a steps block and a success block?
The steps block will only execute if the build result is currently successful...
The success block will only execute if the build result is currently successful...
One suggestion that abayer suggested to me is that effectively each "step" in a success or failure block would be kind of "wrapped" in a try...catch so that all the steps would be executed in that block...
To me, that makes it hard to construct inter-sequencing of steps that should happen on success and steps that should happen always followed by steps that should happen on success... we currently have not defined the execution sequence of the components of the conditional blocks in the notifications and I argue that actually we should just follow declaration order and allow conditions to be repeated...
So that leads to perhaps the only place where I would expect a difference in behaviour for a "step" in a steps block vs a success block... Failure mode...
A "step" in a steps block that has failed should fail the build... a "step" in a success block that has failed should "error" the build... the build has not failed but it is in an error state