-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JENKINS-72841] - Pass flow node ID when skipping stage #700
[JENKINS-72841] - Pass flow node ID when skipping stage #700
Conversation
...on/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
Show resolved
Hide resolved
f6c915b
to
f16fa77
Compare
...model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/Utils.groovy
Show resolved
Hide resolved
...model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/Utils.groovy
Outdated
Show resolved
Hide resolved
@dwnusbaum any chance of another review please? |
@jenkinsci/pipeline-model-definition-plugin-developers could someone take a look please? |
- 11: second stage start | ||
- 12: second stage body | ||
- 14: inner-first stage start (probably) | ||
- 6: parallel start |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I guess adding the call to getContext
will break other tests that use Declarative and expect specific IDs as well. Probably worth a PCT run just to understand if the impact is wide enough that we should prep downstream PRs in advance. I filed jenkinsci/bom#3102 to check.
...model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/Utils.groovy
Outdated
Show resolved
Hide resolved
...odel-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/MatrixTest.java
Outdated
Show resolved
Hide resolved
...on/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
Show resolved
Hide resolved
…s/pipeline/modeldefinition/Utils.groovy Co-authored-by: Devin Nusbaum <[email protected]>
Co-authored-by: Devin Nusbaum <[email protected]>
@timja Yes sorry I'm just running the OSS BOM and another proprietary PCT suite to see if it's worth trying to adjust |
@@ -238,15 +244,16 @@ class ModelInterpreter implements Serializable { | |||
SkippedStageReason skippedReason) { | |||
return { | |||
script.stage(thisStage.name) { | |||
def flowNodeId = getFlowNodeId() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still waiting on the full results, but so far this breaks some tests in blueocean-pipeline-api-impl
and another ~10 spread across some proprietary plugins I have access to:
blueocean-pipeline-api-impl / io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeTest.sequentialParallelStagesWithPost
blueocean-pipeline-api-impl / io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeTest.submitInputPostBlock
blueocean-pipeline-api-impl / io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeTest.declarativeSyntheticSteps
blueocean-pipeline-api-impl / io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeTest.encodedStepDescription
blueocean-pipeline-api-impl / io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeTest.submitInputPostBlockWithParallelStages
blueocean-pipeline-api-impl / io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeTest.declarativeSyntheticSkippedStage
Maybe we could move the call to getFlowNodeId
inside of skipStage
so that the changes only affects tests that are directly related to skipped stages?
EDIT: Those are all the failures in the two PCT runs I did.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bd14425 will hopefully help with this, but tests like PipelineNodeTest.declarativeSyntheticSkippedStag
will probably still need to be adjusted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
created a test run in jenkinsci/blueocean-plugin#2555
I tried to run locally but I can't get the plugin to build due to a like 6 year old npm / node version and unmaintained dependencies 😢
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to run locally but I can't get the plugin to build due to a like 6 year old npm / node version and unmaintained dependencies 😢
Yep, I ran into the same issue in jenkinsci/blueocean-plugin#2540.
With the latest changes, the total affected tests went from 15 to 6, so that's nice. The only remaining affected test in Blue Ocean appears to be blueocean-pipeline-api-impl / io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeTest.submitInputPostBlockWithParallelStages
. Here's the output:
org.junit.ComparisonFailure: expected:<[47]> but was:<[50]>
at org.junit.Assert.assertEquals(Assert.java:117)
at org.junit.Assert.assertEquals(Assert.java:146)
at io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeTest.submitInputPostBlockWithParallelStages(PipelineNodeTest.java:2314)
Let's try to update your Blue Ocean PR to fix the test. There are other tests that will need to be updated internally in CloudBees, but I will take care of that. I'll work on all of this later today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I've pushed a guess in timja/blueocean-plugin@5184941
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to run locally but I can't get the plugin to build due to a like 6 year old npm / node version and unmaintained dependencies 😢
Yep, I ran into the same issue in jenkinsci/blueocean-plugin#2540.
Based on a suggestion by @batmat, I tried building this plugin in the environment created by https://github.com/jenkinsci/blueocean-plugin/blob/1ce0c18265882733f3251dcad0b4af616da5a7c9/Dockerfile.build and it built just fine on my AMD64 system. So while definitely annoying, building this plugin locally is not insurmountable on AMD64. Presumably there is some way to run AMD64 code on ARM64 via emulation/virtualization, where the same Dockerfile.build
could be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn’t even work on amd64 macOS for me. Sure you can make it work on docker.
I’ve got a branch locally that has made a fair bit of progress but now need to update the JS builder and figure out who has access to release there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(jenkinsci/blueocean-plugin#2557 more work to go though)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got it working in jenkinsci/blueocean-plugin#2558
This should help reduce the number of tests that need to be adjusted to update FlowNode IDs.
I pushed bd14425 to try to reduce the number of impacted tests and will rerun the PCT once a new incremental build is available. If nothing else it at least prevents us from having to update |
I triggered another PCT run (just a CloudBees internal one this time) and will check the results tomorrow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit awkward to use getContext
like this, and it's annoying that it affects some tests, but even so, this seems preferable to the kind of approach that was used before and in #698. I've prepped some CloudBees-internal PRs to fix affected tests and will keep an eye on the build of jenkinsci/blueocean-plugin#2555. Once it looks like we've got things working there I'll go ahead and merge this to get a release out.
@@ -222,6 +223,11 @@ class ModelInterpreter implements Serializable { | |||
|
|||
} | |||
|
|||
@NonCPS | |||
private String getFlowNodeId() { | |||
return script.getContext(FlowNode.class).getId() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we not use the withContext
step? It is intended for use in (really) power user trusted libraries, and it is just going to add overhead to the flow node graph for every Declarative build (as well as breaking tons of tests).
Would be better to add some helper method to Utils
that is run silently, without recording a flow node.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we not use the withContext step?
getContext
It is intended for use in (really) power user trusted libraries
What is ModelInterpreter.groovy
if not an incredibly complicated trusted library written by power users?
and it is just going to add overhead to the flow node graph for every Declarative build
One extra FlowNode
per skipped stage. I do not think this is a big problem.
as well as breaking tons of tests
It breaks 6 known tests across OSS plugins and CloudBees-internal plugins, and PRs have already been filed to fix all of them.
Would be better to add some helper method to Utils that is run silently, without recording a flow node.
Yes, but here is the problem: Declarative has only a stage name, and wants to add/update tags on the corresponding FlowNode
objects. Without an initial FlowNode
to guide the scan, we have to scan the whole FlowGraph
, and I am suspicious that there are some unfixable bugs with that approach given duplicate stage names in complex Pipelines. #698 shows that kind of approach. I think it is much clearer to just get a contextual ID to guide the search and the tradeoffs of having to use getContext
do not seem that severe.
Perhaps the code could be adjusted to check the current heads and guess which one is the right one, but I think that is still problematic. For example if you use matrix
and have two identically named stages/parallel branches, but then only one of them gets skipped, it does not seem trivial to figure out which is the "right" one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps the code could be adjusted to check the current heads and guess which one is the right one, but I think that is still problematic. For example if you use matrix and have two identically named stages/parallel branches, but then only one of them gets skipped, it does not seem trivial to figure out which is the "right" one.
Maybe CpsThread.head
could be used to avoid this problem, but I am not sure, particularly given its Javadoc (and it is package private, but that would not stop Groovy here).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without an initial
FlowNode
to guide the scan
I see, this is the crux of the problem: there actually is no obvious Java/Groovy to call that would return usable information at this point. CpsThread.current().etc()
would be tricky.
TagsAction
on all relevant stages #698Before:
After:
see jenkinsci/pipeline-graph-view-plugin#220