jenkins-gitlab-merge-request-builder-plugin icon indicating copy to clipboard operation
jenkins-gitlab-merge-request-builder-plugin copied to clipboard

Published 20 hours ago • verified publisher icon timols

New build scheduled every cron iteration regardless of a previously completed build

Open AndrewJack opened this issue 11 years ago • 14 comments

Steps:

  1. Setup plugin as specified
  2. Create a merge request
  3. Leave merge request there for several cron iterations

Expected: Should check if it has previously been built then only build if it has been changed Actual: Merge request is built every time the cron job is run.

AndrewJack avatar Mar 11 '14 17:03 AndrewJack

:+1: When I installed the plugin it started building all open merge requests every 5 minutes. I had to remove Jenkins job to stop the process.

It would be great if the plugin not only checked if MR was built, but also checked if MR was updated since the last build.

gornostal avatar Mar 11 '14 19:03 gornostal

Is this different to https://github.com/timols/jenkins-gitlab-merge-request-builder-plugin/issues/27?

I've only ever come across this issue for very long builds. Its a known issue.

timols avatar Mar 11 '14 21:03 timols

I noticed #27 and changed the cron job to every 10 minutes (my build taking 6mins) however I still found that the build was being triggered every time the cron job ran.

AndrewJack avatar Mar 11 '14 22:03 AndrewJack

screen shot 2014-03-12 at 17 48 54

AndrewJack avatar Mar 12 '14 17:03 AndrewJack

All for same MR.

I may have a look myself when I get some time.

AndrewJack avatar Mar 12 '14 17:03 AndrewJack

I experience the same issue. Despite build takes about a minute and polling is scheduled with 10 minutes interval, each open MR is build every 10 minutes. Can I do something to help debugging the issue?

kamazee avatar Apr 04 '14 18:04 kamazee

Well, my issue was not really an issue. Plug-in wasn't able to find its recent note for merge request because GitLab returned username lowercased but configured username letters' case was a bit different. I'm not sure whether plug-in should normalize username that was configured, but it's at least worth a couple of words in README.

kamazee avatar Apr 08 '14 09:04 kamazee

That fixed it for me. I made everything lowercase (username, fullname), and now it's working properly.

jerbob92 avatar Jun 03 '14 07:06 jerbob92

@kamazee would you mind forking and adding the relevant comment to the README?

timols avatar Jun 04 '14 14:06 timols

@timols not at all, will do.

kamazee avatar Jun 04 '14 14:06 kamazee

Thanks! :smile:

timols avatar Jun 04 '14 14:06 timols

@timols since barely anyone ever reads docs carefully, would it be OK to normalize username for comparison by lowercasing it instead of just dropping a line into README?

kamazee avatar Jun 10 '14 14:06 kamazee

Well, anyway :) Suggested solution is in #77 However, I can just leave a note in README if the solution seems dirty.

kamazee avatar Jul 24 '14 15:07 kamazee

Just to add a new way to reproduce this (actually it's kind of the same). We have a set up where we have linked Crowd logins to gitlab. This results in some slightly odd behaviour as the crowd user name used to login is not the same as the user name that gitlab associates with the account. As far as I can tell if I have the following crowd user:

gitlab will report the user name as pete.halliday (ie. it extracts it from the email) - I've no idea what it does if they conflict.

Anyway it seems that the user name used in the API calls may not always be super predictable.

I would suggest that a general note is made to check the user name used by gitlab when this issue of infinitely rebuilding merge requests is encountered.

It would also be nice to reference this URL that can be used to check the user name as gitlab sees it.

https://your.gitlab.server/api/v3/user?private_token=YOUR_PRIVATE_TOKEN

Note the username field in the response.

See Gitlab API docs

pghalliday avatar Oct 16 '14 10:10 pghalliday