oleo65 commented 6 years ago

Issue

We are using a multibranch pipeline via JENKINSFILE to be triggered by Gitlab and to report the build status of the various stages to Gitlab.

This was all working properly until the last updates of plugins were fetched. I am not quite sure if the problem we encounter is a bug with your plugin or a different dependant plugin. I attached the relevant part of the Build log and snippets from our Jenkinsfile which I created following your documentation.

Context

Gitlab plugin version: 1.5.6
Gitlab version: 10.8.3-ee
Jenkins version: 2.121.1
Job type: Mulitbranch Pipeline

Logs & Traces

Running in Durability level: MAX_SURVIVABILITY
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: 13: Expecting "null" but got "Package Restore" of type class java.lang.String instead @ line 13, column 24.
                gitlabCommitStatus("Package Restore")
                          ^

1 error

    at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
    at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
    at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
    at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
    at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
    at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
    at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
    at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
    at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
    at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:131)
    at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125)
    at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560)
    at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521)
    at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:325)
    at hudson.model.ResourceController.execute(ResourceController.java:97)
    at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE

Jenkinsfile:

pipeline 
{
    agent any

    stages 
    {
        stage('Package Restore')
        {
            steps
            {
                gitlabCommitStatus("Package Restore")
                {
                    ...
                }
            }
        }
        stage('Build') 
        {
            steps 
            {
                gitlabCommitStatus('Build')
                {
                    ...
                }
            }
        }
        stage('Test')
        {
            steps
            {
                gitlabCommitStatus('Test')
                {
                    ...
                }
            }
        }
    }
    options
    {
        gitLabConnection('GitLab')
        gitlabBuilds(builds: ['Package Restore', 'Build', 'Test'])
    }
    triggers
    {
        gitlab(triggerOnPush: true, triggerOnMergeRequest: true)
    }
}

Thank you for your support or pointing me in the right direction.

I am happy to support you with further assistance if needed.

oleo65 commented 6 years ago

Ok. Follow up notice.

We got this fixed by explicitely stating the parameter for gitlabCommitStatus:

gitlabCommitStatus('Test') changing to gitlabCommitStatus(name: 'Test')

Maybe there should be a note in the documentation about this change in the behaviour.

omehegan commented 6 years ago

@oleo65 thanks for letting me know about this. I think maybe something changed in Pipeline, and you updated one of those plugins, which caused this to break. The workflow-cps-plugin classes that are referenced in the stack trace have not changed in 2+ years.

@abayer or @svanoort does this ring a bell for you: gitlabCommitStatus('Package Restore') has to be changed to gitlabCommitStatus(name: 'Package Restore') in a Pipeline, or else Jenkins throws WorkflowScript: 13: Expecting "null" but got "Package Restore" of type class java.lang.String instead @ line 13, column 24. This appears to have been caused by a recent change... somewhere. I can update our doc to specify the new syntax, presuming that it will be backwards-compatible.

omehegan commented 6 years ago

@oleo65 maybe you could check your Jenkins plugins directory and see which ones were upgraded recently. It might help narrow down what changed.

oleo65 commented 6 years ago

Thank you very much for your support, this is greatly appreciated. :-)

I tried to find out which plugins were updated which is not a straightforward task. The only place I somehow found information update the past (last) update procedure was in the jenkins.err.log. We updated all plugins on that day that were available for update:

I tried to sort the list by possible relevance...

Git
Step API <-- This would be my guess
Pipeline: Multibranch
GitLab
GitHub
GitHub API
GitHub Branch Source
Favorite
Subversion
Apache HttpComponents Client 4.x API
JIRA
Some more Docker plugins which we are currently not using.

My guess is one of the first 3 (4) plugins. I hope this helps! :-)

omehegan commented 6 years ago

Related to #813?

stchar commented 6 years ago

@omehegan, Yep it looks really close to #813.

omehegan commented 6 years ago

@stchar yeah but this is interesting, the issue was reported with version 1.5.6 of the plugin, and that pre-dates your changes which caused the other issues around Pipeline support. @crussell52 see above - your issue was related to 1.5.9 and you said rolling back to 1.5.8 fixed it, but this person is reporting the same problem in 1.5.6. Hmm.

stchar commented 6 years ago

If it's true, and plugin version was submitted accurate, than it means that some changes in stapler might cause it.

crussell52 commented 6 years ago

@omehegan, @stchar

Sorry I can't include links and using pseudo code because I'm on phone, but check the file history of the status step class.

Around Jan (1.5.6?) construct(Str name) was removed. It was later added back in a commit mentioning backwards compatibility (754832a) - released in 1.58. The same constructor was removed again in 1.5.9

So I think these look the same because it was broken on two separate occasions

omehegan commented 6 years ago

Hmm, I dug through the file history and did not see any changes in January. @stchar refactored that in 1.5.7, which broke some Pipeline users, then fixed it in 1.5.8... The prior change to this class was from May 2017, and did not touch that method.

crussell52 commented 6 years ago

@omehegan, Apologies... side effects of mobile. I was referring to 7b8c52400 -- Looks like it was originally committed in Jan, but maybe didn't get merged until May? Regardless, you are correct in that the first release it showed up in was v1.5.7.

More specifically, the history I'm looking at is:

In 7b8c52400 (v1.5.7), it was replaced with public GitLabCommitStatusStep(String name, List<GitLabBranchBuild> builds, GitLabConnectionProperty connection)
In 754832a (v1.5.8), the (String name) constructor returned and the symptoms not present.
In 799e4332 (v1.5.9), it was removed again -- this time in favor of public GitLabCommitStatusStep() and the symptoms are present.

This report was made on Jun 11th and mentioned the "latest version"; 1.5.7 would have been the latest version at the time, by about 2 weeks. In 1.5.7 and 1.5.9 are both missing the public GitLabCommitStatusStep(String name). To be fair, this is a bit of guesswork for me... I am not familiar with the details of writing pipeline plugins nor groovy transformations, in general. But this seems very suspect to me since the broken usage appears to correspond to that (String name) constructor.

(Continuing the guesswork), I suspect adding that constructor back in -- without removing the newer constructor -- will probably achieve the desired effect of 799e4332 (name being optional when using named args) without breaking the older usage where name is given as a positional arg.

Edit: Additionally, https://issues.jenkins-ci.org/browse/JENKINS-52267 reports the broken gitlab gitlabCommitStatus() usage that is said to be fixed by 754832a -- the commit where the (String name) constructor returns.

omehegan commented 6 years ago

@crussell52 thanks a lot for poking around in this further! For now I'll wait on the resolution of #813 and see if it helps this reporter as well.

oleo65 commented 6 years ago

First of all, thank you everybody for your feedback and investigations. This is very much appreciated.

I have some trouble to retrieve the used versions at the time of writing this ticket. But the plugin manager shows that we migrated directly from v. 1.5.6 to 1.5.9 which is also what I recalled. So the mentioned software revisions from the first post are correct.

I hope this helps.

omehegan commented 6 years ago

@oleo65 thanks for confirming. Please monitor #813 and let us know if the fix for that does not resolve this issue for you.

omehegan commented 5 years ago

813 has been fixed in 1.5.11. Please reopen if that does not resolve this issue.

jenkinsci / gitlab-plugin

gitlabCommitStatus fails with null exception #781

Issue

Context

Logs & Traces

813 has been fixed in 1.5.11. Please reopen if that does not resolve this issue.