RE: Pipeline: Expected call wound up catching different method

[Reinhold Füreder]

Thanks a lot for the clarification/enlightenment, Devin!


From: jenkinsci-users@googlegroups.com  On 
Behalf Of Devin Nusbaum
Sent: Dienstag, 30. Juli 2019 16:49
To: jenkinsci-users@googlegroups.com
Subject: Re: Pipeline: Expected call wound up catching different method

Sverre mentioned that checkUpstream and checkDownstream call “build” and 
“println”. Since “build” can be an async step if you pass "wait: true”, and I 
wasn’t sure exactly how they were using it, I recommended removing @NonCPS from 
those methods.

If checkUpstream and checkDownstream only use “build" in non-async mode, and 
“releaseUtility.getReleaseBranch” does not call any async Pipeline steps or 
other CPS-transformed code, then I think you should be able to annotate that 
method with @NonCPS in "vars/releaseUtility.groovy" and have everything work 
correctly.

I don’t think either solution is clearly best. I would avoid using @NonCPS 
unless you have a clear need for it (perhaps because of a bug with some Groovy 
feature specific to the CPS transformation, or because the overhead of the CPS 
transformation is causing problems), and even though steps like “echo” work 
fine inside of an @NonCPS method I think it’s a lot easier to just avoid using 
Pipeline steps inside of @NonCPS entirely.

Thanks,
Devin


On Jul 30, 2019, at 03:15, Reinhold Füreder 
mailto:r.fuere...@xortex.com>> wrote:

Sorry to bring this up again, but I am just curious:

Sverre wrote (a) „Both these methods [(checkUpstream and checkDownstream)] 
make[s] a call toreleaseUtility.getReleaseBranch.” and (b) that both are 
annotated with “@NonCPS” and (c) that the latter 
(releaseUtility.getReleaseBranch) is defined in “vars/releaseUtility.groovy“

And he also asks “I guess then getReleaseBranch needs to also be annotated with 
NonCPS.”

@Devin:

  *   Is annotating getReleaseBranch() with @NonCPS in 
“vars/releaseUtility.groovy“ section (1) allowed and (2) therefore the best 
solution?
  *   Or is getReleaseBranch()in “vars/releaseUtility.groovy“ section actually 
a proper pipeline step and so annotating with@NonCPS actually wrong, and so 
@NonCPS must also be removed from checkUpstream and checkDownstream as you 
suggested?

Thanks,
Reinhold


--
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
jenkinsci-users+unsubscr...@googlegroups.com<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/DB8PR01MB6156A8F569E89602288F1547F7DC0%40DB8PR01MB6156.eurprd01.prod.exchangelabs.com<https://groups.google.com/d/msgid/jenkinsci-users/DB8PR01MB6156A8F569E89602288F1547F7DC0%40DB8PR01MB6156.eurprd01.prod.exchangelabs.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
jenkinsci-users+unsubscr...@googlegroups.com<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/1FDB7E46-771B-4018-A074-AF9702669F9A%40cloudbees.com<https://groups.google.com/d/msgid/jenkinsci-users/1FDB7E46-771B-4018-A074-AF9702669F9A%40cloudbees.com?utm_medium=email_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/AM0PR01MB614743FCD3E901FD29D73165F7DF0%40AM0PR01MB6147.eurprd01.prod.exchangelabs.com.

Re: Pipeline: Expected call wound up catching different method

[Devin Nusbaum]

Sverre mentioned that checkUpstream and checkDownstream call “build” and 
“println”. Since “build” can be an async step if you pass "wait: true”, and I 
wasn’t sure exactly how they were using it, I recommended removing @NonCPS from 
those methods.

If checkUpstream and checkDownstream only use “build" in non-async mode, and 
“releaseUtility.getReleaseBranch” does not call any async Pipeline steps or 
other CPS-transformed code, then I think you should be able to annotate that 
method with @NonCPS in "vars/releaseUtility.groovy" and have everything work 
correctly.

I don’t think either solution is clearly best. I would avoid using @NonCPS 
unless you have a clear need for it (perhaps because of a bug with some Groovy 
feature specific to the CPS transformation, or because the overhead of the CPS 
transformation is causing problems), and even though steps like “echo” work 
fine inside of an @NonCPS method I think it’s a lot easier to just avoid using 
Pipeline steps inside of @NonCPS entirely.

Thanks,
Devin

> On Jul 30, 2019, at 03:15, Reinhold Füreder  wrote:
> 
> Sorry to bring this up again, but I am just curious:
>  
> Sverre wrote (a) „Both these methods [(checkUpstream and checkDownstream)] 
> make[s] a call toreleaseUtility.getReleaseBranch.” and (b) that both are 
> annotated with “@NonCPS” and (c) that the latter 
> (releaseUtility.getReleaseBranch) is defined in “vars/releaseUtility.groovy“
>  
> And he also asks “I guess then getReleaseBranch needs to also be annotated 
> with NonCPS.”
>  
> @Devin:
> Is annotating getReleaseBranch() with @NonCPS in “vars/releaseUtility.groovy“ 
> section (1) allowed and (2) therefore the best solution?
> Or is getReleaseBranch()in “vars/releaseUtility.groovy“ section actually a 
> proper pipeline step and so annotating with@NonCPS actually wrong, and so 
> @NonCPS must also be removed from checkUpstream and checkDownstream as you 
> suggested?
>  
> Thanks,
> Reinhold
>  
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-users+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/DB8PR01MB6156A8F569E89602288F1547F7DC0%40DB8PR01MB6156.eurprd01.prod.exchangelabs.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/1FDB7E46-771B-4018-A074-AF9702669F9A%40cloudbees.com.

RE: Pipeline: Expected call wound up catching different method

[Reinhold Füreder]

Sorry to bring this up again, but I am just curious:

Sverre wrote (a) „Both these methods [(checkUpstream and checkDownstream)] 
make[s] a call to releaseUtility.getReleaseBranch.” and (b) that both are 
annotated with “@NonCPS” and (c) that the latter 
(releaseUtility.getReleaseBranch) is defined in “vars/releaseUtility.groovy“

And he also asks “I guess then getReleaseBranch needs to also be annotated with 
NonCPS.”

@Devin:

  *   Is annotating getReleaseBranch() with @NonCPS in 
“vars/releaseUtility.groovy“ section (1) allowed and (2) therefore the best 
solution?
  *   Or is getReleaseBranch()in “vars/releaseUtility.groovy“ section actually 
a proper pipeline step and so annotating with @NonCPS actually wrong, and so 
@NonCPS must also be removed from checkUpstream and checkDownstream as you 
suggested?

Thanks,
Reinhold

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/DB8PR01MB6156A8F569E89602288F1547F7DC0%40DB8PR01MB6156.eurprd01.prod.exchangelabs.com.

Re: Pipeline: Expected call wound up catching different method

[Devin Nusbaum]

Your Pipeline should be working exactly as it did before, now you are just 
getting a log message (unless you are using jenkinsfile-runner, in which case 
an exception is thrown instead, see JENKINS-58407) warning that it has probably 
never worked correctly , although depending on exactly what the method does you 
might not have noticed. The wiki page at 
https://jenkins.io/redirect/pipeline-cps-method-mismatches/ 
 gives some 
background on this warning and how to prevent it and is worth reading if you 
see this error.

It’s hard to say without seeing your whole Pipeline, but it looks like you are 
running into a variant of the first item under the “Common Problems and 
Solutions” section on the wiki page, and the fix would be to just to remove 
`@NonCPS` from `checkUpstream` and `checkDownstream` if these methods are in 
fact calling Pipeline steps.

> On Jul 26, 2019, at 11:07, Sverre Moe  wrote:
> 
> I got a problem with my Pipeline which has worked fine up until recently.
> I don't quite understand what the problem is:
> 
> expected to call Build.checkUpstream but wound up catching 
> releaseUtility.getReleaseBranch; see: 
> https://jenkins.io/redirect/pipeline-cps-method-mismatches/ 
> 
> expected to call Build.checkDownstream but wound up catching 
> releaseUtility.getReleaseBranch; see: 
> https://jenkins.io/redirect/pipeline-cps-method-mismatches/ 
> 
> 
> src/no/company/ci/Build.groovy
> @NonCPS void checkUpstream(upstreamDependencies, projectName, 
> buildEnvironment, releasePackages)
> @NonCPS void checkDownstream(downstreamDependencies, projectName, 
> buildEnvironment, releasePackages)
> 
> vars/releaseUtility.groovy
> def getReleaseBranch(projectName, buildEnvironment, releasePackages)
> 
> 
> The checkUpstream goes through all upstream projects, find out which has 
> failed and trigger a build on them
> The checkDownstream does the same for upstream projects.
> 
> Both these methods makes a call to releaseUtility.getReleaseBranch.
> 
> Is this the reason? "it is impossible for non-CPS-transformed code to call 
> CPS-transformed code"
> I guess then getReleaseBranch needs to also be annotated with NonCPS.
> 
> Maybe I no longer need NonCPS on checkUpstream and checkDownstream (ref 
> JENKINS-26481  mentioned 
> in the URL above).
> These methods do not call node or sh step (just build and println). They do 
> access the Jenkins instance to jenkinsInstance.getItemByFullName and getting 
> all the jobs for it.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-users+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/15494592-78a8-4e87-b687-be4eac9d7891%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/C9E2B31B-7B63-4F97-8A8F-7CDAF18AB7C6%40cloudbees.com.

Pipeline: Expected call wound up catching different method

[Sverre Moe]

I got a problem with my Pipeline which has worked fine up until recently.
I don't quite understand what the problem is:

expected to call Build.checkUpstream but wound up catching 
releaseUtility.getReleaseBranch; see: 
https://jenkins.io/redirect/pipeline-cps-method-mismatches/
expected to call Build.checkDownstream but wound up catching 
releaseUtility.getReleaseBranch; see: 
https://jenkins.io/redirect/pipeline-cps-method-mismatches/


src/no/company/ci/Build.groovy

@NonCPS void checkUpstream(upstreamDependencies, projectName, 
buildEnvironment, releasePackages)
@NonCPS void checkDownstream(downstreamDependencies, projectName, 
buildEnvironment, releasePackages)


vars/releaseUtility.groovy

def getReleaseBranch(projectName, buildEnvironment, releasePackages)



The checkUpstream goes through all upstream projects, find out which has failed 
and trigger a build on them

The checkDownstream does the same for upstream projects.


Both these methods makes a call to releaseUtility.getReleaseBranch.


Is this the reason? "it is impossible for non-CPS-transformed code to call 
CPS-transformed code"

I guess then getReleaseBranch needs to also be annotated with NonCPS.


Maybe I no longer need NonCPS on checkUpstream and checkDownstream (ref 
JENKINS-26481  mentioned in 
the URL above).

These methods do not call node or sh step (just build and println). They do 
access the Jenkins instance to jenkinsInstance.getItemByFullName and 
getting all the jobs for it.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/15494592-78a8-4e87-b687-be4eac9d7891%40googlegroups.com.