Skip to content
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

Merged
merged 9 commits into from
Apr 10, 2024

Conversation

timja
Copy link
Member

@timja timja commented Mar 11, 2024

Before:
image

After:

image

see jenkinsci/pipeline-graph-view-plugin#220

@timja timja added the bug label Mar 11, 2024
@timja timja requested a review from dwnusbaum March 11, 2024 19:34
@timja timja marked this pull request as draft March 11, 2024 19:35
@timja timja force-pushed the JENKINS-72841-use-step-context branch from f6c915b to f16fa77 Compare March 11, 2024 20:18
@timja timja marked this pull request as ready for review March 11, 2024 20:23
@timja timja requested review from dwnusbaum and removed request for dwnusbaum March 11, 2024 20:23
@timja timja marked this pull request as draft March 11, 2024 20:57
@timja timja requested a review from dwnusbaum March 11, 2024 22:52
@timja timja marked this pull request as ready for review March 11, 2024 22:53
@timja timja requested a review from a team March 12, 2024 08:42
@timja
Copy link
Member Author

timja commented Mar 13, 2024

@dwnusbaum any chance of another review please?

@timja timja requested a review from joseblas March 15, 2024 11:10
@timja timja requested review from a team and removed request for a team March 24, 2024 14:31
@timja
Copy link
Member Author

timja commented Mar 24, 2024

@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
Copy link
Member

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.

@timja timja requested a review from dwnusbaum April 9, 2024 15:57
@dwnusbaum
Copy link
Member

@timja Yes sorry I'm just running the OSS BOM and another proprietary PCT suite to see if it's worth trying to adjust getContext to only be called when a stage is going to be skipped to avoid having to update a bunch of tests.

@@ -238,15 +244,16 @@ class ModelInterpreter implements Serializable {
SkippedStageReason skippedReason) {
return {
script.stage(thisStage.name) {
def flowNodeId = getFlowNodeId()
Copy link
Member

@dwnusbaum dwnusbaum Apr 9, 2024

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.

Copy link
Member

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.

Copy link
Member Author

@timja timja Apr 10, 2024

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 😢

Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member Author

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)

Copy link
Member Author

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.
@dwnusbaum
Copy link
Member

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 ParallelTest here.

@dwnusbaum
Copy link
Member

dwnusbaum commented Apr 9, 2024

I triggered another PCT run (just a CloudBees internal one this time) and will check the results tomorrow.

Copy link
Member

@dwnusbaum dwnusbaum left a 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.

@dwnusbaum dwnusbaum merged commit 41dd8ef into jenkinsci:master Apr 10, 2024
15 checks passed
@@ -222,6 +223,11 @@ class ModelInterpreter implements Serializable {

}

@NonCPS
private String getFlowNodeId() {
return script.getContext(FlowNode.class).getId()
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

@dwnusbaum dwnusbaum Apr 11, 2024

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).

Copy link
Member

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.

@timja timja deleted the JENKINS-72841-use-step-context branch April 11, 2024 14:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Some skipped steps are wrongly displayed as in progress
4 participants