Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
RHEL 6
Description
We have a job setup to build pull request branches based on a naming convention on the branches. The branch specifier is /pr/. We have 'Execute concurrent builds if necessary' turned on for this job and sometimes Jenkins will kick off 4-5 builds for the same branch at the same time and fill up the executors. I've tried adding a quiet period but that didn't seem to help.
Attachments
Issue Links
- relates to
-
-
- Open
-
Activity
Colin Bennett
added a comment - I confirm the existence of this bug. Apparently since the Git plugin is looking only at the last completed build's Git commit hash, concurrent builds are not identified.
The solution is probably to implement something like the Groovy script jskjons posted above, except implement it in the Git plugin directly. If manually triggered, we might actually want to rebuild the same commit twice concurrently (different parameters? want to compare consistency of test runs?) but for polling we would only expect to fire up a single build for a particular commit.
Colin Bennett
added a comment - I confirm the existence of this bug. Apparently since the Git plugin is looking only at the last completed build's Git commit hash, concurrent builds are not identified.
The solution is probably to implement something like the Groovy script jskjons posted above, except implement it in the Git plugin directly. If manually triggered, we might actually want to rebuild the same commit twice concurrently (different parameters? want to compare consistency of test runs?) but for polling we would only expect to fire up a single build for a particular commit. Colin Bennett
added a comment - The bug still exists with Git plugin v2.4.4 and Jenkins v1.642.3.
I can see why it exists, since if the last built commit is X, and then Y is committed, a build is triggered for commit Y and the last build data in Jenkins is for X. But if polling happens again (in my case due to a GitLab web hook posting to Jenkins) then a second concurrent build will be started for commit Y, since the last completed build was for X.
Colin Bennett
added a comment - The bug still exists with Git plugin v2.4.4 and Jenkins v1.642.3.
I can see why it exists, since if the last built commit is X, and then Y is committed, a build is triggered for commit Y and the last build data in Jenkins is for X. But if polling happens again (in my case due to a GitLab web hook posting to Jenkins) then a second concurrent build will be started for commit Y, since the last completed build was for X. I don't know Java very well. Is this the place where a new build is scheduled to run?
Is this method the right place to check for existing running builds?
Use multibranch projects and you will not suffer from this kind of problem.
Hi there. I use git-plugin 2.3.5 and this issue exists.
Job starts a few times.
I fetch changes from repo from branch with slashes(feature/test). And after this job execution job starts few times and doesn't find any changes.
I know that branches with slashes it is another Jenkins issue but job starts a few times anyway.