Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Critical
-
Resolution: Fixed
-
Component/s: git-plugin
-
Labels:None
-
Similar Issues:
Description
I've just downloaded Jenkins 1.434 to see wether the last comment in #JENKINS-7554 from Christian Weiske is true that the newest git plugin solves the problems with the GIT_BRANCH/GIT_COMMIT envvars and setting the build up to build multiple branches.
Unfortunately it turns out that the plugin does not support building multiple branches anymore at all. No matter wether I leave the branch field empty or add multiple branches to the build configuration it always only builds master. Tried with a totally fresh job so all branches need to be considered 'updated' and polling as well as manual building.
Attachments
Issue Links
- is duplicated by
-
-
- Closed
-
-
JENKINS-22591 Does not spawn build if a branch refers to the same SHA1 as another already built branch
-
- Closed
-
Activity
OK, alternative strategies could work, but it just occurred to me - strategy return a list of revisions and… it would make sense that those revisions should be built. Instead the list seems to be ignored (vide mentioend GitSCM.java:1018).
Would it be possible to actually stick and execute what strategy returned and build it? I can easily return list of what needed to build in strategy, but it doesn't seem binding.
(One possible solution that comes to my mind would be to leverage parametrized build and then pass each resulting revisions/branches as a parameter that could be configured in scheduled jobs, and immediately schedule same number of jobs as many revisions were returned by strategy)
Wojtek
added a comment - - edited OK, alternative strategies could work, but it just occurred to me - strategy return a list of revisions and… it would make sense that those revisions should be built. Instead the list seems to be ignored (vide mentioend GitSCM.java:1018).
Would it be possible to actually stick and execute what strategy returned and build it? I can easily return list of what needed to build in strategy, but it doesn't seem binding.
(One possible solution that comes to my mind would be to leverage parametrized build and then pass each resulting revisions/branches as a parameter that could be configured in scheduled jobs, and immediately schedule same number of jobs as many revisions were returned by strategy) I'm a little more skeptical of passing parameters because parameter passing has created security issues.
You might consider making changes to the plugin to allow the new strategy you create to alter the default behavior for jobs which use that strategy. If the new strategy was being used, then the lower levels of the git plugin would build all revisions, instead of building all revisions which have not yet been built.
Mark Waite – Okay, can you do the above? Because otherwise the git plugin is kinda broken for us right now.
Brad Knowles no, unfortunately, I cannot. I have other priorities in git plugin maintenance and won't investigate this topic further for a long time.
Unfortunately, I don't have any good suggestion for alternatives.
You're correct that I'm not willing to change default behavior. I am open to consider additional build strategies which apply different rules.