[JIRA] (JENKINS-37731) syntax for SCMTrigger in pipelineTriggers

95 views
Skip to first unread message

daniel@jasek.org (JIRA)

unread,
Aug 26, 2016, 8:04:01 PM8/26/16
to jenkinsc...@googlegroups.com
Dan Jasek created an issue
 
Jenkins / Bug JENKINS-37731
syntax for SCMTrigger in pipelineTriggers
Issue Type: Bug Bug
Assignee: Unassigned
Components: core
Created: 2016/Aug/27 12:03 AM
Priority: Minor Minor
Reporter: Dan Jasek

From what I can tell this syntax should work for defining an SCMTrigger within Jenkinsfile:

properties([
    pipelineTriggers([
        scm('H/5 * * * *')
    ])
])

For comparison, this works for the TimerTrigger:

properties([
    pipelineTriggers([
        cron('H/5 * * * *')
    ])
])

As a workaround, this does work correctly:

properties([
    pipelineTriggers([
        [$class: "SCMTrigger", spec: "H/5 * * * *"],
    ])
])

This is the error I get when using scm:

hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: hudson.plugins.git.GitSCM.call() is applicable for argument types: (java.lang.String) values: [H/5 * * * *]
Possible solutions: all(), wait(), any(), wait(long), each(groovy.lang.Closure), any(groovy.lang.Closure)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:58)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:64)
at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:151)
at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:21)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:115)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:103)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146)
at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:16)
at WorkflowScript.run(WorkflowScript:12)
at __cps.transform__(Native Method)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:48)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
at sun.reflect.GeneratedMethodAccessor275.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
at com.cloudbees.groovy.cps.Next.step(Next.java:58)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:164)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:361)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:236)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:226)
at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:47)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Finished: FAILURE
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

daniel@jasek.org (JIRA)

unread,
Aug 26, 2016, 8:05:01 PM8/26/16
to jenkinsc...@googlegroups.com
Dan Jasek updated an issue
Change By: Dan Jasek
From what I can tell this syntax should work for defining an SCMTrigger within Jenkinsfile:

{code}

properties([
    pipelineTriggers([
        scm('H/5 * * * *')
    ])
])
{code}


For comparison, this works for the TimerTrigger:

{code}

properties([
    pipelineTriggers([
        cron('H/5 * * * *')
    ])
])
{code}


As a workaround, this does work correctly:

{code}
properties([
    pipelineTriggers([
        [$class: "SCMTrigger", spec scmpoll_spec : "H/5 * * * *"],
    ])
])
{code}


This is the error I get when using scm:

hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: hudson.plugins.git.GitSCM.call() is applicable for argument types: (java.lang.String) values: [H/5 * * * *]
Possible solutions: all(), wait(), any(), wait(long), each(groovy.lang.Closure), any(groovy.lang.Closure)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:58)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:64)
at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:151)
at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:21)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:115)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:103)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146)
at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:16)
at WorkflowScript.run(WorkflowScript:12)
at ___cps.transform___(Native Method)

jglick@cloudbees.com (JIRA)

unread,
Aug 29, 2016, 10:51:01 AM8/29/16
to jenkinsc...@googlegroups.com
Jesse Glick assigned an issue to Andrew Bayer
Change By: Jesse Glick
Assignee: Andrew Bayer

jglick@cloudbees.com (JIRA)

unread,
Aug 29, 2016, 10:52:02 AM8/29/16
to jenkinsc...@googlegroups.com
Jesse Glick commented on Bug JENKINS-37731
 
Re: syntax for SCMTrigger in pipelineTriggers

What version of Jenkins? What does Snippet Generator suggest?

jglick@cloudbees.com (JIRA)

unread,
Aug 29, 2016, 10:53:03 AM8/29/16
to jenkinsc...@googlegroups.com

And what versions of Pipeline: Groovy and Pipeline: Job?

andrew.bayer@gmail.com (JIRA)

unread,
Aug 29, 2016, 11:55:01 AM8/29/16
to jenkinsc...@googlegroups.com

I'm working on this on workflow-job 2.6 and workflow-cps 2.14-SNAPSHOT...snippet generator tests fail on both 1.642 and 2.7, with errors like 

WARNING: failed to uncoerce hudson.triggers.SCMTrigger@380ba0e6
java.lang.UnsupportedOperationException: no public field ‘scmpoll_spec’ (or getter method) found in class hudson.triggers.SCMTrigger

This particular issue in the snippet generator comes back to the utter pain-in-the-buttness that the constructor parameter name in SCMTrigger is scmpoll_spec, but there's no field named scmpoll_spec (with getters/setters/etc) in SCMTrigger - it just calls super(scmpoll_spec) so it's actually exposed as Trigger.spec. Naming inconsistencies, man.

Buuuuut the actual 'splosion seen here is something else. Figuring that out now.

andrew.bayer@gmail.com (JIRA)

unread,
Aug 29, 2016, 12:06:01 PM8/29/16
to jenkinsc...@googlegroups.com

So the error - the scm symbol isn't trumping the scm object, which...well, makes sense. So we need a different symbol in core on SCMTrigger - and while we're there, I think we should try to switch off scmpoll_spec if at all possible, given the problems that causes. Jesse Glick - thoughts?

andrew.bayer@gmail.com (JIRA)

unread,
Aug 29, 2016, 12:08:01 PM8/29/16
to jenkinsc...@googlegroups.com

That was on core 2.7.2, fyi.

andrew.bayer@gmail.com (JIRA)

unread,
Aug 29, 2016, 12:16:02 PM8/29/16
to jenkinsc...@googlegroups.com

Also worth noting that scmpoll_spec is nothing but a parameter name. The XML serialization of SCMTrigger uses spec, since that's what the getter in the parent is for. So I think it's worth breaking.

dbeck@cloudbees.com (JIRA)

unread,
Aug 29, 2016, 12:19:02 PM8/29/16
to jenkinsc...@googlegroups.com

So I think it's worth breaking.

TBH `DataboundConstructor` seem very brittle given they rely on parameter names…

Note that with https://github.com/jenkins-infra/repository-permissions-updater/blob/5d2d9720e95e59fdeb91b0000626aed4d1b23d83/Jenkinsfile#L3 there's at least one Jenkinsfile in the wild that relies on that parameter name. Would require https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions

andrew.bayer@gmail.com (JIRA)

unread,
Aug 29, 2016, 12:26:01 PM8/29/16
to jenkinsc...@googlegroups.com

Hrm. Since we're in core and not a plugin, that just makes things more fun. I guess a @Deprecated constructor may make sense?

andrew.bayer@gmail.com (JIRA)

unread,
Aug 29, 2016, 12:54:03 PM8/29/16
to jenkinsc...@googlegroups.com

Got a possible fix incoming. We shall see. =)

andrew.bayer@gmail.com (JIRA)

unread,
Aug 29, 2016, 1:38:02 PM8/29/16
to jenkinsc...@googlegroups.com
Andrew Bayer started work on Bug JENKINS-37731
 
Change By: Andrew Bayer
Status: Open In Progress

andrew.bayer@gmail.com (JIRA)

unread,
Aug 29, 2016, 1:38:04 PM8/29/16
to jenkinsc...@googlegroups.com
Change By: Andrew Bayer
Status: In Progress Review

andrew.bayer@gmail.com (JIRA)

unread,
Aug 29, 2016, 1:39:01 PM8/29/16
to jenkinsc...@googlegroups.com
 
Re: syntax for SCMTrigger in pipelineTriggers

PRs up and linked in core and multibranch.

scm_issue_link@java.net (JIRA)

unread,
Sep 6, 2016, 10:01:07 AM9/6/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Andrew Bayer
Path:
pom.xml
src/test/java/org/jenkinsci/plugins/workflow/multibranch/JobPropertyStepTest.java
http://jenkins-ci.org/commit/workflow-multibranch-plugin/1b68fff0b887c9c64570b43262561c09d222cec3
Log:
JENKINS-37731 Tests for proper handling of SCMTrigger in step.

Note that we're pretty much stuck with SCMTrigger not working right
with the snippet generator pre-core-2.21 (or whenever
https://github.com/jenkinsci/jenkins/pull/2526 lands). SCMTrigger is
just busted vis a vis the Snippet Generator. So what we're doing here
is testing runtime syntax, and snippet generation against core with a
new enough version to have the "pollScm" symbol on SCMTrigger's descriptor.

Also enabled/fixed some snippetizer round trip tests that now can
work, while I was here.

scm_issue_link@java.net (JIRA)

unread,
Sep 6, 2016, 10:01:08 AM9/6/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Andrew Bayer
Path:
pom.xml
src/test/java/org/jenkinsci/plugins/workflow/multibranch/JobPropertyStepTest.java

JENKINS-37731 Tests for proper handling of SCMTrigger in step.

scm_issue_link@java.net (JIRA)

unread,
Sep 9, 2016, 9:36:03 AM9/9/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Andrew Bayer
Path:

core/src/main/java/hudson/triggers/SCMTrigger.java
core/src/main/resources/hudson/triggers/SCMTrigger/config.jelly
http://jenkins-ci.org/commit/jenkins/75745f00428226d648ccbee899f2970adf51c899
Log:
[FIXED JENKINS-37731] Change symbol and constructor for SCMTrigger. (#2526)

  • [FIXED JENKINS-37731] Change symbol and constructor for SCMTrigger.

Using "scm" as the @Symbol led to collisions with the "scm" global
variable in Pipeline, so that had to go. Changed it to "pollScm". Also
moved the @DataBoundConstructor to the single-parameter constructor,
deprecated the two-parameter constructor, created a @DataBoundSetter
for ignorePostCommitHooks, and added a getter for "scmpoll_spec" to
fix snippet generator and general syntactic goodness.

So now, with this, it's possible to do:

properties([
pipelineTriggers([
pollScm('@daily')
])
])

Tada.

Tests for the snippet generator and job property stuff will be landing
in a separate PR for workflow-multibranch.

  • Review comments.
  • Updating @since to 2.22

andrew.bayer@gmail.com (JIRA)

unread,
Sep 9, 2016, 11:25:04 AM9/9/16
to jenkinsc...@googlegroups.com
 

Merged and will be released in core 2.22.
Change By: Andrew Bayer
Status: In Review Resolved
Resolution: Fixed
Reply all
Reply to author
Forward
0 new messages