Additional builds triggered for commit even if current commit is building

[mjdetullio]

Basically, there is a race condition between your job's build time and the merge request builder cron setting. The race causes the same commit hash to be built twice or even several times.

Setup:

• Jenkins job that takes more than "X" minutes to build (i.e. 5 minutes)
• Gitlab Merge Request Builder cron is set to poll every "X" minutes (i.e. same as above, 5 minutes = */5 * * * *)

Result:

1. Cron picks up a new merge request to build
2. After "X" (5) minutes, Gitlab Merge Request Builder triggers a second build while the first one is still building.
3. First build finished and posts the comment on the merge request, sets commit as built.
4. No additional builds are triggered (if cron is fast enough, a third or fourth could have been triggered for example)
5. Second build finished and posts a second comment on the merge request, even though the same reference was built.

Updating a merge request with a new commit or amended commit should still work as intended and trigger a new build.

Workaround: Slow down your cron!

[timols]

Yes. I've noticed this too. I'm planning on adding a check to prevent builds being scheduled if one is already running. Thanks for reporting.

[jchristi]

Workaround: Slow down your cron. Thx mjdetullio :)

[jchristi]

@timols any progress on this one? If not then I might be able to help out with this if you can point me in the right direction. Thanks.

[mjdetullio]

Currently the plugin relies on GitLab's API to tell if a MR is building or was built. When the build triggered comment is disabled, the last comment left will still be from before the last commit.

You have to either:

1. Reenable the build triggered message (at the expense of extra comments/emails in your MRs)
2. Modify the plugin's build trigger to not schedule a build if a build is already running or queued. However, if a new change comes in when that condition is met, you'd miss a build, so you need to add logic the compare the commits

[timols]

@jchristi pretty much what @mjdetullio said. The plugin was implemented using the comments to keep track of the state of the build in certain circumstances, so if the messages are disabled, then the plugin will struggle to not re-build.

1. Modify the plugin's build trigger to not schedule a build if a build is already running or queued. However, if a new change comes in when that condition is met, you'd miss a build, so you need to add logic the compare the commits

Yep, the challenge lies in adjusting the build trigger to look at all other builds.

[davidkovaccs]

I've just created #107 that solved this issue for us

[dodoinblue]

@davidkovaccs the fix works. thx.