-
New Feature
-
Resolution: Fixed
-
Major
-
Jenkins 1.631
Workflow plugin(s): 1.10.1
GIT Plugin: 2.4.0
I am encountering an unclear exception when executing "checkout scm".
As far as I know, all plugins (workflow, git) should be up-to-date and compatible (see Environment).
I am running the following workflow script from SCM (git).
stage 'Build'
node('slave2') {
checkout scm
}
which fails with the following trace.
groovy.lang.MissingPropertyException: No such property: scm for class: groovy.lang.Binding at groovy.lang.Binding.getVariable(Binding.java:62) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:141) at org.kohsuke.groovy.sandbox.impl.Checker$4.call(Checker.java:241) at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:238) at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:221) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.getProperty(SandboxInvoker.java:23) at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:17) at WorkflowScript.run(WorkflowScript:3) at Unknown.Unknown(Unknown) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:62) at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30) at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:54) at sun.reflect.GeneratedMethodAccessor1121.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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:145) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19) 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:106) 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:271) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$000(CpsThreadGroup.java:71) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:180) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:178) at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:47) at java.util.concurrent.FutureTask.run(FutureTask.java:262) 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:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)
- is related to
-
JENKINS-26100 SCM steps should return revision state
-
- Resolved
-
- relates to
-
JENKINS-42817 readTrusted Pipeline from SCM only works in */master
-
- Closed
-
- links to
[JENKINS-31386] "checkout scm" does not work in standalone jobs
At the same time, would be appropriate to make the default Script Path be Jenkinsfile rather than flow.groovy as today, so there would be better alignment and a smooth migration path to multibranch.
Code changed in jenkins
User: Jesse Glick
Path:
CHANGES.md
cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/CpsScmFlowDefinition/config.jelly
cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/CpsScmFlowDefinition/help-scriptPath.html
multibranch/src/main/java/org/jenkinsci/plugins/workflow/multibranch/SCMVar.java
multibranch/src/main/resources/org/jenkinsci/plugins/workflow/multibranch/SCMVar/help.jelly
multibranch/src/test/java/org/jenkinsci/plugins/workflow/multibranch/SCMVarTest.java
http://jenkins-ci.org/commit/workflow-plugin/fe22dc9fa39267239e6ca16001bd9cd97b0ee48c
Log:
[FIXED JENKINS-31386] Define the scm var in standalone projects using CpsScmFlowDefinition.
Code changed in jenkins
User: Jesse Glick
Path:
CHANGES.md
cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/CpsScmFlowDefinition/config.jelly
cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/CpsScmFlowDefinition/help-scriptPath.html
multibranch/src/main/java/org/jenkinsci/plugins/workflow/multibranch/SCMVar.java
multibranch/src/main/resources/org/jenkinsci/plugins/workflow/multibranch/SCMVar/help.jelly
multibranch/src/test/java/org/jenkinsci/plugins/workflow/multibranch/SCMBinderTest.java
multibranch/src/test/java/org/jenkinsci/plugins/workflow/multibranch/SCMVarTest.java
http://jenkins-ci.org/commit/workflow-plugin/c91ed650071362d9949da5fbffd13a9262c1fb1e
Log:
JENKINS-31386 Merging #264.
Compare: https://github.com/jenkinsci/workflow-plugin/compare/85330f60060d...c91ed6500713
Mitya Kononchuk
added a comment - jglick isn't it possible to make checkout scm strict also in standalone mode? That would be extremely useful, as when you have multi-repositories pipelines you are doomed to stuck with standalone builds. You can get information about what commit was used by the SCM e.g. from the build actions: currentBuild.rawBuild.getActions(hudson.plugins.git.util.BuildData.class)[0].lastBuiltRevision.sha1String
Mitya Kononchuk
added a comment - jglick isn't it possible to make checkout scm strict also in standalone mode? That would be extremely useful, as when you have multi-repositories pipelines you are doomed to stuck with standalone builds. You can get information about what commit was used by the SCM e.g. from the build actions: currentBuild.rawBuild.getActions(hudson.plugins.git.util.BuildData.class)[0].lastBuiltRevision.sha1String Code changed in jenkins
User: Jesse Glick
Path:
cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/CpsScmFlowDefinition/config.jelly
cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/CpsScmFlowDefinition/help-scriptPath.html
http://jenkins-ci.org/commit/workflow-cps-plugin/154cf757f25f0ea9124cb579227d15084c522191
Log:
[FIXED JENKINS-31386] Define the scm var in standalone projects using CpsScmFlowDefinition.
Originally-Committed-As: fe22dc9fa39267239e6ca16001bd9cd97b0ee48c
Code changed in jenkins
User: Jesse Glick
Path:
cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/CpsScmFlowDefinition/config.jelly
cps/src/main/resources/org/jenkinsci/plugins/workflow/cps/CpsScmFlowDefinition/help-scriptPath.html
http://jenkins-ci.org/commit/workflow-cps-plugin/e3e8029b441bda842acc7520f21f863c9d062e00
Log:
JENKINS-31386 Merging #264.
Originally-Committed-As: c91ed650071362d9949da5fbffd13a9262c1fb1e
Code changed in jenkins
User: Jesse Glick
Path:
multibranch/src/main/java/org/jenkinsci/plugins/workflow/multibranch/SCMVar.java
multibranch/src/main/resources/org/jenkinsci/plugins/workflow/multibranch/SCMVar/help.jelly
multibranch/src/test/java/org/jenkinsci/plugins/workflow/multibranch/SCMVarTest.java
http://jenkins-ci.org/commit/workflow-multibranch-plugin/1bb763830b78e2d93ce0f5fb53954646736a662e
Log:
[FIXED JENKINS-31386] Define the scm var in standalone projects using CpsScmFlowDefinition.
Originally-Committed-As: fe22dc9fa39267239e6ca16001bd9cd97b0ee48c
checkout scm is currently only available for multibranch workflows, not for standalone jobs. However I think it could be made to work in standalone jobs using the Workflow script from SCM definition.
It would be weaker since it would only be a shortcut for specifying an equivalent SCM definition in the script body, whereas in multibranch projects the scm variable is actually guaranteed to check out the same revision as Jenkinsfile was using. (Consider a commit pushed to the SCM between the time the Workflow script is checked out, and the time the checkout step runs. In a standalone project, the checkout step will pick up the new commit, whereas in a multibranch project scm will use the original commit. That could matter in case you are making changes coördinated between the Workflow script and other project sources, such as this one.)