[JIRA] (JENKINS-42473) Cannot get property 'stages' on null object

2 views
Skip to first unread message

domi@fortysix.ch (JIRA)

unread,
Mar 3, 2017, 12:01:01 PM3/3/17
to jenkinsc...@googlegroups.com
Dominik Bartholdi created an issue
 
Jenkins / Bug JENKINS-42473
Cannot get property 'stages' on null object
Issue Type: Bug Bug
Assignee: Andrew Bayer
Components: pipeline-model-definition-plugin
Created: 2017/Mar/03 5:00 PM
Environment: pipeline model definition: 1.0.1
Jenkins: 2.32.2.4 (DEV@Cloud by cloudbees)
Priority: Major Major
Reporter: Dominik Bartholdi

I have the following simple pipeline:

@Library("yooture@test")
import org.foo.Zot

pipeline {
    agent any
    stages {
        stage('Example') {
            steps {
                echo 'Hello World'
            }
        }
    }
    post {
        always {
            echo 'I will always say Hello again!'
        }
    }
}

I have the same pipeline in two separate repos in a branch called `develop` (copy/paste).

In the repo called 'dummy' the job runs fine and the output is like this:

Started by user Dominik Bartholdi
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url g...@bitbucket.org:yooture/dummy.git # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/dummy.git
 > git --version # timeout=10
using GIT_SSH to set credentials empty PK to force use of cloudbees dev PK
 > git fetch --tags --progress g...@bitbucket.org:yooture/dummy.git +refs/heads/develop
Checking out Revision bb79c694a8e87299efa63e40e07ead81ca1dafae (develop)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f bb79c694a8e87299efa63e40e07ead81ca1dafae
 > git rev-list bb79c694a8e87299efa63e40e07ead81ca1dafae # timeout=10
[Bitbucket] Notifying commit build result
Loading library yooture@test
 > git rev-parse --is-inside-work-tree # timeout=10
Setting origin to g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git
 > git config remote.origin.url g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git # timeout=10
Fetching origin...
Fetching upstream changes from origin
 > git --version # timeout=10
 > git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/*
 > git rev-parse test^{commit} # timeout=10
 > git rev-parse origin/test^{commit} # timeout=10
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git
 > git --version # timeout=10
 > git fetch --tags --progress g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git +refs/heads/*:refs/remotes/origin/*
Checking out Revision 3ca0c91267dcdad0ca87753530d6ccc72052de6d (test)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3ca0c91267dcdad0ca87753530d6ccc72052de6d
 > git rev-list 3ca0c91267dcdad0ca87753530d6ccc72052de6d # timeout=10
[Bitbucket] Notifying commit build result
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor
Running on 4301da39 in /scratch/jenkins/workspace/yooture_dummy_develop-4RA5EAL6PUY5FQWEW4F5AGDHPLRE77ZYZYEPJ66GZIF5EPSC45DA
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
Cloning the remote Git repository
Cloning repository g...@bitbucket.org:yooture/dummy.git
 > git init /scratch/jenkins/workspace/yooture_dummy_develop-4RA5EAL6PUY5FQWEW4F5AGDHPLRE77ZYZYEPJ66GZIF5EPSC45DA # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/dummy.git
 > git --version # timeout=10
using GIT_SSH to set credentials empty PK to force use of cloudbees dev PK
 > git fetch --tags --progress g...@bitbucket.org:yooture/dummy.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url g...@bitbucket.org:yooture/dummy.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git config remote.origin.url g...@bitbucket.org:yooture/dummy.git # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/dummy.git
using GIT_SSH to set credentials empty PK to force use of cloudbees dev PK
 > git fetch --tags --progress g...@bitbucket.org:yooture/dummy.git +refs/heads/develop
Checking out Revision bb79c694a8e87299efa63e40e07ead81ca1dafae (develop)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f bb79c694a8e87299efa63e40e07ead81ca1dafae
[Bitbucket] Notifying commit build result
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Example)
[Pipeline] echo
Hello World
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Declarative: Post Actions)
[Pipeline] echo
I will always say Hello again!
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
[Bitbucket] Notifying commit build result
[Bitbucket] Build result notified
Finished: SUCCESS

in the repo called 'yooture' the same pipeline fails with this output:

Branch indexing
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url g...@bitbucket.org:yooture/yooture.git # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/yooture.git
 > git --version # timeout=10
using GIT_SSH to set credentials empty PK to force use of cloudbees dev PK
 > git fetch --tags --progress g...@bitbucket.org:yooture/yooture.git +refs/heads/develop
Checking out Revision fb7b7daa3ee2d456edd67b7ec00f944edd969526 (develop)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f fb7b7daa3ee2d456edd67b7ec00f944edd969526
 > git rev-list 449077e7df4f085fd35f284314df4e0ee57ff91c # timeout=10
[Bitbucket] Notifying commit build result
Loading library yooture@test
 > git rev-parse --is-inside-work-tree # timeout=10
Setting origin to g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git
 > git config remote.origin.url g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git # timeout=10
Fetching origin...
Fetching upstream changes from origin
 > git --version # timeout=10
 > git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/*
 > git rev-parse test^{commit} # timeout=10
 > git rev-parse origin/test^{commit} # timeout=10
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git
 > git --version # timeout=10
 > git fetch --tags --progress g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git +refs/heads/*:refs/remotes/origin/*
Checking out Revision 3ca0c91267dcdad0ca87753530d6ccc72052de6d (test)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3ca0c91267dcdad0ca87753530d6ccc72052de6d
 > git rev-list d18ccc986483746586e1db7b3b4f09245efd73d8 # timeout=10
[Bitbucket] Notifying commit build result
[Pipeline] End of Pipeline
[Bitbucket] Notifying commit build result
[Bitbucket] Build result notified
java.lang.NullPointerException: Cannot get property 'stages' on null object
	at org.codehaus.groovy.runtime.NullObject.getProperty(NullObject.java:60)
	at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:172)
	at org.codehaus.groovy.runtime.callsite.NullCallSite.getProperty(NullCallSite.java:47)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:296)
	at org.jenkinsci.plugins.pipeline.modeldefinition.Utils.attachDeclarativeActions(Utils.groovy:198)
	at org.jenkinsci.plugins.pipeline.modeldefinition.Utils$attachDeclarativeActions$7.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 com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:18)
	at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.call(jar:file:/home/yooture/hudson_home/plugins/pipeline-model-definition/WEB-INF/lib/pipeline-model-definition.jar!/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy:64)
	at WorkflowScript.run(WorkflowScript:4)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
	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.GeneratedMethodAccessor346.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.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:76)
	at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
	at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:66)
	at sun.reflect.GeneratedMethodAccessor350.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:163)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:328)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:240)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:228)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:63)
	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

As you can see from the commit hashes, the exact same version of the shared library is used: 3ca0c91267dcdad0ca87753530d6ccc72052de6d (test)

The shared library (branch test) has only one file: src/org/foo/Zot.groovy - but its not even used within the pipeline script.

package org.foo;

def echo(msg) {
  echo "-> ${msg}"
}

This is as far as I was able to break down the issue, but now I'm absolutely lost and have no further ideas on how to debug this issue.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

domi@fortysix.ch (JIRA)

unread,
Mar 3, 2017, 12:19:01 PM3/3/17
to jenkinsc...@googlegroups.com
Dominik Bartholdi commented on Bug JENKINS-42473
 
Re: Cannot get property 'stages' on null object

to make the whole thing even more strange, I tried the following: I forked a branch from 'yooture/develop' repository (repo/branch) to yooture/feature/empty_branch_test2 and it works:

Branch indexing
Cloning the remote Git repository
Cloning repository g...@bitbucket.org:yooture/yooture.git
 > git init /home/yooture/hudson_home/workspace/_feature_empty_branch_test2-TR4FWR4O7Y5ZH2REBHUBTGTVWO2ULVEWLS4DS4YN6RJIJTTJZVWQ@script # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/yooture.git
 > git --version # timeout=10
using GIT_SSH to set credentials empty PK to force use of cloudbees dev PK
 > git fetch --tags --progress g...@bitbucket.org:yooture/yooture.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url g...@bitbucket.org:yooture/yooture.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git config remote.origin.url g...@bitbucket.org:yooture/yooture.git # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/yooture.git
using GIT_SSH to set credentials empty PK to force use of cloudbees dev PK
 > git fetch --tags --progress g...@bitbucket.org:yooture/yooture.git +refs/heads/feature/empty_branch_test2
Checking out Revision fb7b7daa3ee2d456edd67b7ec00f944edd969526 (feature/empty_branch_test2)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f fb7b7daa3ee2d456edd67b7ec00f944edd969526
First time build. Skipping changelog.
[Bitbucket] Notifying commit build result
Loading library yooture@test
 > git rev-parse --is-inside-work-tree # timeout=10
Setting origin to g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git
 > git config remote.origin.url g...@bitbucket.org:
yooture/yooture-jenkins-pipeline-libraries.git # timeout=10
Fetching origin...
Fetching upstream changes from origin
 > git --version # timeout=10
 > git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/*
 > git rev-parse test^{commit} # timeout=10
 > git rev-parse origin/test^{commit} # timeout=10
Cloning the remote Git repository
Cloning repository g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git
 > git init /home/yooture/hudson_home/workspace/_feature_empty_branch_test2-TR4FWR4O7Y5ZH2REBHUBTGTVWO2ULVEWLS4DS4YN6RJIJTTJZVWQ@libs/yooture # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git
 > git --version # timeout=10
 > git fetch --tags --progress g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git config remote.origin.url g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git
 > git fetch --tags --progress g...@bitbucket.org:yooture/yooture-jenkins-pipeline-libraries.git +refs/heads/*:refs/remotes/origin/*
Checking out Revision 3ca0c91267dcdad0ca87753530d6ccc72052de6d (test)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3ca0c91267dcdad0ca87753530d6ccc72052de6d
First time build. Skipping changelog.
[Bitbucket] Notifying commit build result
[Pipeline] node
Running on df0ffc03 in /scratch/jenkins/workspace/_feature_empty_branch_test2-TR4FWR4O7Y5ZH2REBHUBTGTVWO2ULVEWLS4DS4YN6RJIJTTJZVWQ
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
Cloning the remote Git repository
Cloning repository g...@bitbucket.org:yooture/yooture.git
 > git init /scratch/jenkins/workspace/_feature_empty_branch_test2-TR4FWR4O7Y5ZH2REBHUBTGTVWO2ULVEWLS4DS4YN6RJIJTTJZVWQ # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/yooture.git
 > git --version # timeout=10
using GIT_SSH to set credentials empty PK to force use of cloudbees dev PK
 > git fetch --tags --progress g...@bitbucket.org:yooture/yooture.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url g...@bitbucket.org:yooture/yooture.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git config remote.origin.url g...@bitbucket.org:yooture/yooture.git # timeout=10
Fetching upstream changes from g...@bitbucket.org:yooture/yooture.git
using GIT_SSH to set credentials empty PK to force use of cloudbees dev PK
 > git fetch --tags --progress g...@bitbucket.org:yooture/yooture.git +refs/heads/feature/empty_branch_test2
Checking out Revision fb7b7daa3ee2d456edd67b7ec00f944edd969526 (feature/empty_branch_test2)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f fb7b7daa3ee2d456edd67b7ec00f944edd969526
[Bitbucket] Notifying commit build result
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Example)
[Pipeline] echo
Hello World
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Declarative: Post Actions)
[Pipeline] echo
I will always say Hello again!
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
[Bitbucket] Notifying commit build result
[Bitbucket] Build result notified
Finished: SUCCESS

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 12:23:04 PM3/3/17
to jenkinsc...@googlegroups.com

That...is deeply weird. Somehow, the Jenkinsfile is parsing correctly at compilation time, but when we re-parse it for attaching the execution plan to the build (so that Blue Ocean can visualize what's going to run), it's not finding the pipeline block. The relevant code is here - yes, we are using reflection black magic to get the source we're running so we can reparse it, which must be where things are going wrong...

domi@fortysix.ch (JIRA)

unread,
Mar 3, 2017, 12:27:02 PM3/3/17
to jenkinsc...@googlegroups.com

yeah, and only in one specific branch in one repo... - is there any kind of cache that could hold on on something for any reason?

domi@fortysix.ch (JIRA)

unread,
Mar 3, 2017, 12:31:02 PM3/3/17
to jenkinsc...@googlegroups.com

ah and btw. if I remove/comment the Library and import stuff from the top, then it works...

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 12:33:03 PM3/3/17
to jenkinsc...@googlegroups.com

Huh. Then I'd guess that somehow, the CpsFlowExecution we're getting from CpsScript via reflection is giving us the Library loaded scripts contents instead of the Jenkinsfile contents? I think I've got a better way of doing the load now - using the same mechanism for getting the CpsFlowExecution that ReplayAction uses. Any chance you could test with a SNAPSHOT?

domi@fortysix.ch (JIRA)

unread,
Mar 3, 2017, 12:36:01 PM3/3/17
to jenkinsc...@googlegroups.com

I would really love to test it, but you would need to convince your colleagues running DEV@cloud - since they have this new approval process and release cycles its a pain in the a... to get anything updated in a reasonable time...

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 12:39:02 PM3/3/17
to jenkinsc...@googlegroups.com

I was afraid of that. Grr. Ok, time to try all kinds of weird stuff to reproduce this!

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 12:42:01 PM3/3/17
to jenkinsc...@googlegroups.com

Oh, a couple other questions: this is a multibranch setup? And is there anything distinctive about the configuration for the develop branch? Or its build history? Any chance you could send me the config.xml for the develop branch?

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 12:43:02 PM3/3/17
to jenkinsc...@googlegroups.com

And assuming it's a multibranch setup, the config.xml for the repo would be great. And if it's an org folder (or whatever the equivalent term is for BitBucket), that config.xml too. =)

domi@fortysix.ch (JIRA)

unread,
Mar 3, 2017, 1:35:03 PM3/3/17
to jenkinsc...@googlegroups.com

its an org folder (bitbucket) - but dev@cloud does not allow the download of config.xml

domi@fortysix.ch (JIRA)

unread,
Mar 3, 2017, 1:36:02 PM3/3/17
to jenkinsc...@googlegroups.com
Dominik Bartholdi updated an issue
 
Change By: Dominik Bartholdi
Comment: its an org folder (bitbucket) - but dev@cloud does not allow the download of config.xml :(

domi@fortysix.ch (JIRA)

unread,
Mar 3, 2017, 1:38:01 PM3/3/17
to jenkinsc...@googlegroups.com

domi@fortysix.ch (JIRA)

unread,
Mar 3, 2017, 1:39:01 PM3/3/17
to jenkinsc...@googlegroups.com
 
Re: Cannot get property 'stages' on null object

its a bitbucket org folder.. - file attached

domi@fortysix.ch (JIRA)

unread,
Mar 3, 2017, 1:55:03 PM3/3/17
to jenkinsc...@googlegroups.com

domi@fortysix.ch (JIRA)

unread,
Mar 3, 2017, 1:55:04 PM3/3/17
to jenkinsc...@googlegroups.com
Dominik Bartholdi edited a comment on Bug JENKINS-42473
its a bitbucket org folder.. - file attached , both for failing job and org

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 2:38:01 PM3/3/17
to jenkinsc...@googlegroups.com
Andrew Bayer started work on Bug JENKINS-42473
 
Change By: Andrew Bayer
Status: Open In Progress

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 2:39:01 PM3/3/17
to jenkinsc...@googlegroups.com

Ok, my initial theory (that the CpsFlowExecution.script was different than it should be) turned out not to be the case, but I am now able to reproduce this, so digging deeper!

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 3:04:01 PM3/3/17
to jenkinsc...@googlegroups.com

So it's somehow ending up trying to do the reparsing for Zot.groovy after doing it for the Jenkinsfile, which results in a null model. I know how to keep this from happening, but I want to write a test for it before I do the fix...

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 3:05:01 PM3/3/17
to jenkinsc...@googlegroups.com

Especially because I have no idea how the ordering is happening such that when it's a branch named develop it does this, but when it's a branch named feature/something-or-other, it doesn't. Wuh.

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 3:21:03 PM3/3/17
to jenkinsc...@googlegroups.com

Ok, it's not the branch name - it's first run vs later. On first run, Zot.groovy isn't included in the source list. On later runs, it is.

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 4:41:03 PM3/3/17
to jenkinsc...@googlegroups.com

andrew.bayer@gmail.com (JIRA)

unread,
Mar 3, 2017, 4:42:01 PM3/3/17
to jenkinsc...@googlegroups.com

scm_issue_link@java.net (JIRA)

unread,
Mar 6, 2017, 7:01:02 PM3/6/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Andrew Bayer
Path:
pipeline-model-definition/pom.xml
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/BasicModelDefTest.java
pom.xml
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/b4bd7fd29639c3bc95902d61bdf60c4e5f4203fb
Log:
Reproduce JENKINS-42473 failure.

Required bumping git plugin version, running in a folder, and making
the git plugin a direct dependency rather than a test dependency. phew.

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

scm_issue_link@java.net (JIRA)

unread,
Mar 6, 2017, 7:01:02 PM3/6/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Andrew Bayer
Path:

pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/Utils.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/Converter.groovy
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/944d34f7b8269380b411113a94f1e63e750c6c33
Log:
JENKINS-42473 Use a better way of getting the flow execution

Not sure yet if this will actually solve the problem, but it seems
superior regardless. I lifted this from ReplayAction.

andrew.bayer@gmail.com (JIRA)

unread,
Mar 6, 2017, 7:01:02 PM3/6/17
to jenkinsc...@googlegroups.com
Change By: Andrew Bayer
Status: In Review Resolved
Resolution: Fixed

scm_issue_link@java.net (JIRA)

unread,
Mar 6, 2017, 7:01:02 PM3/6/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Andrew Bayer
Path:

pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/Converter.groovy
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/bd692a56a92193d4a2fe74423a4435836709fc92
Log:
[FIXED JENKINS-42473] Only do parsing if WorkflowScript

Deals with cases where there are multiple SourceUnits in the CompilationUnit.

bitwiseman@gmail.com (JIRA)

unread,
Oct 22, 2019, 11:24:57 PM10/22/19
to jenkinsc...@googlegroups.com
Liam Newman closed an issue as Fixed
 

Bulk closing resolved issues.

Change By: Liam Newman
Status: Resolved Closed
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages