Open melissafritcher opened 7 years ago
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.
@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.
@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/
It's there now. Testing today. Thanks!
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.
@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
Hey folks, this is still an issue. Let me know if y'all need more logs, etc.
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.
Thanks, I will have to try and reproduce this, but my spare time for working on the plugin is limited right now.
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
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.