Including shared library causes extra builds to be queued on MR edit

[melissafritcher]

Issue

Including a shared Library, causes any edits to an MR (such as adding a label) to create another build, even when builds for the latest commit have already started.

Context

• Gitlab plugin version: 1.4.2
• Gitlab version: 8.13.1-ee 3f76553
• Jenkins version: 2.32.3
• Job type: Pipeline

Logs & Traces

Jenkins GItlab Plugin.txt

Problem description

Using the simple pipeline groovy script below, when the @Library reference is excluded, an MR is created and built as expected. Editing the MR to change the labels does not start a new build. You can see this behaviour in the fix/2build2 branch in the logs.

When the @Library call is included, an MR is created and a build is started as expected. Then before the original build is finished, if the labels are updated on the MR, a new build is incorrectly queued. It seems similar to Issue #523, except I am on the Pipeline Multibranch plugin v 2.12 and not using Multibranch Pipelines.

//Pipeline groovy 
// in the log, branch fix/2build2 is the one without the library include; the fix/2build4 branch is the one with the @Library
//@Library('jenkins-sharedlibs')

graphitePrefix = ""
cookbookName = "pipeline_test"
gitUrl = "<GITLAB_URL>"
credentialsId = "<CREDENTIALS>"
productionBranch = "master"
maxParallel = 4
 node('master') {
      //Create a new workspace for gem jobs that have spaces replaced with underscores.
      //Spaces seem to break some jobs
      ws(env.JOB_NAME.replaceAll(' ','_')) {
        deleteDir()
        checkout([$class: 'GitSCM', branches: [[name: sourceBranch()]], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: credentialsId, url: gitUrl]]])
    sleep(120)
      }
 }
   def sourceBranch() {
      if (env.gitlabSourceBranch != null)
        return env.gitlabSourceBranch
      return 'master'
    }

[omehegan]

Let's watch for the fix in #562 to be merged, and see if this resolves your problem. I suspect they are related, just due to the underlying changes to the API.

[omehegan]

@melissafritcher version 1.4.6 of the plugin was released today with #562 included. Please test with this and let us know if it resolves your issue.

[melissafritcher]

@omehegan it appears that version 1.4.6 of the plugin is missing from the jenkins mirror site: http://mirrors.jenkins-ci.org/plugins/gitlab-plugin/1.4.6/

[melissafritcher]

It's there now. Testing today. Thanks!

[melissafritcher]

version 1.4.6 does not solve this issue for me.

Opening a new MR and then making any changes (even after a build starts) creates a second build. The "CHANGES" section for these two builds when an MR is open is blank.

Making a push to an open MR and then editing the MR creates two more builds. The changes in the first build is correct (the correct commit SHA is displayed and comments).

The changes in the second build show commits from the library that happened last week.

I've attached the new log the show the events I'm seeing.

JenkinsLogs.txt

[melissafritcher]

@omehegan The gitlab-plugin 1.4.7 that was released this week does not fix this issue for me: Opening a new MR and then making any changes (even after a build starts) creates a second build: The first MR's status page looks like this:

The status page for the second MR looks like this:

Attached are the Gitlab plugin logs: gitlab-plugin1.4.7.txt

[melissafritcher]

Hey folks, this is still an issue. Let me know if y'all need more logs, etc.

[melissafritcher]

This is still an issue.Read https://github.com/jenkinsci/gitlab-plugin/issues/594 and verified that we have been setting gitlab_rails['webhook_timeout'] = 120 for a few months now.

[omehegan]

Thanks, I will have to try and reproduce this, but my spare time for working on the plugin is limited right now.