Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-11337

Git plugin only triggers a build for one branch

    XMLWordPrintable

    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

            Activity

            Hide
            astrofrog Thomas Robitaille added a comment -

            I'm having the same issue. It does seem that Jenkins finds all the branches ('Seen branch in repository ...') but then only proceeds to build one of them. For the specific project I am tracking, there are branches added/removed every day, so I cannot set up a build for each branch.

            Show
            astrofrog Thomas Robitaille added a comment - I'm having the same issue. It does seem that Jenkins finds all the branches ('Seen branch in repository ...') but then only proceeds to build one of them. For the specific project I am tracking, there are branches added/removed every day, so I cannot set up a build for each branch.
            Hide
            mcintyre321 Harry McIntyre added a comment -

            From what I've been reading it sounds like the git plugin merges together all the monitored branches each time there is a change to one of them, and builds that, passing in the branch name of the one that changed as an environment variable.

            Assuming my understanding of this is correct, and this is by design... it sounds to me like there is a different common use case than the one that the plugin is designed for. I think the plugin needs to be extended so that it has an optional mode under which:

            "Any time a branch changes (including when it has commits pushed to it, even if they have already been pushed to a different branch) a new build is queued, and that build is passed the name of the branch that changed as a variable"

            Is this the lack of this the same problem that people are reporting? Does this make any sense?

            Show
            mcintyre321 Harry McIntyre added a comment - From what I've been reading it sounds like the git plugin merges together all the monitored branches each time there is a change to one of them, and builds that, passing in the branch name of the one that changed as an environment variable. Assuming my understanding of this is correct, and this is by design... it sounds to me like there is a different common use case than the one that the plugin is designed for. I think the plugin needs to be extended so that it has an optional mode under which: "Any time a branch changes (including when it has commits pushed to it, even if they have already been pushed to a different branch) a new build is queued, and that build is passed the name of the branch that changed as a variable" Is this the lack of this the same problem that people are reporting? Does this make any sense?
            Hide
            apaku Andreas Pakulat added a comment -

            No I think you misunderstood our description. The Git plugin used to work like this:

            1. Look at all branches and note down which have changed
            2. Kick off a new build for each branch that has changed

            So if I have 5 branches and 3 changed I'd get 3 new builds in the job, one for each branch.

            Show
            apaku Andreas Pakulat added a comment - No I think you misunderstood our description. The Git plugin used to work like this: 1. Look at all branches and note down which have changed 2. Kick off a new build for each branch that has changed So if I have 5 branches and 3 changed I'd get 3 new builds in the job, one for each branch.
            Hide
            astrofrog Thomas Robitaille added a comment -

            +1 to Andreas - that is the behavior that I want too.

            Show
            astrofrog Thomas Robitaille added a comment - +1 to Andreas - that is the behavior that I want too.
            Hide
            mcintyre321 Harry McIntyre added a comment -

            That is also the behaviour I want - and it used to work?

            Show
            mcintyre321 Harry McIntyre added a comment - That is also the behaviour I want - and it used to work?
            Hide
            apaku Andreas Pakulat added a comment -

            Yes, admittingly on a rather old version of Hudson/Git plugin. Hudson is 1.359 and the git plugin is at 1.1.6

            Show
            apaku Andreas Pakulat added a comment - Yes, admittingly on a rather old version of Hudson/Git plugin. Hudson is 1.359 and the git plugin is at 1.1.6
            Hide
            mubbashir Ahmed Mubbashir Khan added a comment -

            Is there any update on this?

            Show
            mubbashir Ahmed Mubbashir Khan added a comment - Is there any update on this?
            Hide
            przemek_dyk Przemek Dyk added a comment -

            I cannot reproduce this bug using jenkins 1.424, 1.497 or 1.502 with git plugin 1.2.0
            Accidentally fixed?

            Show
            przemek_dyk Przemek Dyk added a comment - I cannot reproduce this bug using jenkins 1.424, 1.497 or 1.502 with git plugin 1.2.0 Accidentally fixed?
            Hide
            markewaite Mark Waite added a comment -

            Was fixed a long time ago. Confirmed still working as expected with git client plugin 1.10.1 and git plugin 2.2.2

            Show
            markewaite Mark Waite added a comment - Was fixed a long time ago. Confirmed still working as expected with git client plugin 1.10.1 and git plugin 2.2.2
            Hide
            feystorm Patrick Hemmer added a comment -

            Getting this issue as well. It appears Jenkins suppresses the build for each branch if each branch has the same commit. This poses a problem for us as our build behaves differently based on the branch.

            Still trying to figure out a workaround (multiple jobs isn't viable for us).

            Show
            feystorm Patrick Hemmer added a comment - Getting this issue as well. It appears Jenkins suppresses the build for each branch if each branch has the same commit. This poses a problem for us as our build behaves differently based on the branch. Still trying to figure out a workaround (multiple jobs isn't viable for us).
            Hide
            markewaite Mark Waite added a comment -

            Patrick Hemmer I think you are confusing this resolved bug report with your desire to change the behavior of the git plugin. The git plugin relies on git's assurances that a commit SHA1 uniquely identifies the source code and its history. Since the source code and its history for a single SHA1 are the same no matter which branch we're using, the plugin does not need to build again if the SHA1 has already been built.

            There have been several bug reports where users complained because duplicate builds were being generated. You're now requesting repeated builds of the same SHA1, which look like duplicate builds to the plugin.

            I'm afraid you'll need to find another way to represent your desire to build the same SHA1 multiple times, with a different branch name on different builds.

            Show
            markewaite Mark Waite added a comment - Patrick Hemmer I think you are confusing this resolved bug report with your desire to change the behavior of the git plugin. The git plugin relies on git's assurances that a commit SHA1 uniquely identifies the source code and its history. Since the source code and its history for a single SHA1 are the same no matter which branch we're using, the plugin does not need to build again if the SHA1 has already been built. There have been several bug reports where users complained because duplicate builds were being generated. You're now requesting repeated builds of the same SHA1, which look like duplicate builds to the plugin. I'm afraid you'll need to find another way to represent your desire to build the same SHA1 multiple times, with a different branch name on different builds.
            Hide
            feystorm Patrick Hemmer added a comment -

            Actually I wasn't confusing it at all. The original report mentions nothing about the expected behavior when multiple branches share the same commit, and the scenario I mention easily fits the description.
            I commented to help anyone else who might still be running across this issue, and from the comments, it seems like some people might be.

            If you're saying I should open up a bug report for this behavior, I can do so. But it sounds like you're not interested in adjusting the behavior. In which case I'll simply provide a workaround if/when I come up with one.

            Show
            feystorm Patrick Hemmer added a comment - Actually I wasn't confusing it at all. The original report mentions nothing about the expected behavior when multiple branches share the same commit, and the scenario I mention easily fits the description. I commented to help anyone else who might still be running across this issue, and from the comments, it seems like some people might be. If you're saying I should open up a bug report for this behavior, I can do so. But it sounds like you're not interested in adjusting the behavior. In which case I'll simply provide a workaround if/when I come up with one.
            Hide
            markewaite Mark Waite added a comment -

            Patrick Hemmer you are correct that I'm not interested in changing the behavior in this case.

            If someone else were to submit a pull request to change the behavior, that change would have to be an optional condition, explicitly selected by the user to get the new behavior. I'm reasonably confident that a reasonable subset of the approximately 40000 installations of the git plugin have one or more jobs which depend on the existing behavior.

            Show
            markewaite Mark Waite added a comment - Patrick Hemmer you are correct that I'm not interested in changing the behavior in this case. If someone else were to submit a pull request to change the behavior, that change would have to be an optional condition, explicitly selected by the user to get the new behavior. I'm reasonably confident that a reasonable subset of the approximately 40000 installations of the git plugin have one or more jobs which depend on the existing behavior.
            Hide
            feystorm Patrick Hemmer added a comment -

            Must you keep assuming I mean things which I never say? Sensationalism & exaggeration is not productive either.

            The git plugin is designed such that implementing this behavior does not even require modification of the plugin. It supports additional plugins providing a build branch "choosing strategy". I simply created a new strategy that returns the commit & branch for each branch the job monitors.

            For anyone who may be interested in this, it's available at https://github.com/phemmer/jenkins-git-chooser-build-branches (I have not published it to the official plugin list).

            Show
            feystorm Patrick Hemmer added a comment - Must you keep assuming I mean things which I never say? Sensationalism & exaggeration is not productive either. The git plugin is designed such that implementing this behavior does not even require modification of the plugin. It supports additional plugins providing a build branch "choosing strategy". I simply created a new strategy that returns the commit & branch for each branch the job monitors. For anyone who may be interested in this, it's available at https://github.com/phemmer/jenkins-git-chooser-build-branches (I have not published it to the official plugin list).
            Hide
            markewaite Mark Waite added a comment -

            Thanks for a very nice use of the choosing strategy. I hadn't considered using a branch choosing strategy to solve the problem you're trying to solve.

            I didn't intend to either sensationalize or exaggerate. My sincere apologies for that.

            Since your change is a branch choosing strategy, wouldn't it be preferred to include it in the git plugin directly rather than add another plugin?

            Show
            markewaite Mark Waite added a comment - Thanks for a very nice use of the choosing strategy. I hadn't considered using a branch choosing strategy to solve the problem you're trying to solve. I didn't intend to either sensationalize or exaggerate. My sincere apologies for that. Since your change is a branch choosing strategy, wouldn't it be preferred to include it in the git plugin directly rather than add another plugin?
            Hide
            aje Andrew Erickson added a comment -

            Why was this closed?

            I just had a user request this functionality. It would be nice it was just an option in the git plugin.

            Thanks.

            Show
            aje Andrew Erickson added a comment - Why was this closed? I just had a user request this functionality. It would be nice it was just an option in the git plugin. Thanks.
            Hide
            markewaite Mark Waite added a comment -

            Andrew Erickson this was closed because the original report was confirmed to be closed based on my interpretation of the phrasing of the bug report. The git plugin triggers builds for as many branches as match the "Branches to build" specification and have distinct SHA1 hashes.

            About 4 years after the original bug report, Patrick Hemmer reported that if two branches have the same SHA1 hash, he wanted two separate builds. I noted that is not the way the git plugin operates, that it assumes once a SHA1 has been built, it does not need to be rebuilt. He noted that he was able to implement an extension to the plugin which allows a new choosing strategy that can build the same SHA1 multiple times, once per uniquely named branch.

            Can you be more specific about the functionality that your user requested?

            Show
            markewaite Mark Waite added a comment - Andrew Erickson this was closed because the original report was confirmed to be closed based on my interpretation of the phrasing of the bug report. The git plugin triggers builds for as many branches as match the "Branches to build" specification and have distinct SHA1 hashes. About 4 years after the original bug report, Patrick Hemmer reported that if two branches have the same SHA1 hash, he wanted two separate builds. I noted that is not the way the git plugin operates, that it assumes once a SHA1 has been built, it does not need to be rebuilt. He noted that he was able to implement an extension to the plugin which allows a new choosing strategy that can build the same SHA1 multiple times, once per uniquely named branch. Can you be more specific about the functionality that your user requested?
            Hide
            aje Andrew Erickson added a comment -

            Scenario:

            • Job has multiple 'branches to build' configured.
            • User desires a build of a branch other than the first configured (usually master). 'Build now' will build the first branch.
            • User has no way of triggering a build of the specific branch.

            Current solutions:

            • push a whitespace change to the branch desired to be built
            • create discreet jobs per branch
            • parameterize the job and don't use the git plugin

            Ideal solution:

            ...

            Sorry to restart a long thread.

            Are you open to that solution? Should I open a new ticket with the above content (happy to work on it)?

            Thanks,
            Andy

            Show
            aje Andrew Erickson added a comment - Scenario: Job has multiple 'branches to build' configured. User desires a build of a branch other than the first configured (usually master). 'Build now' will build the first branch. User has no way of triggering a build of the specific branch. Current solutions: push a whitespace change to the branch desired to be built create discreet jobs per branch parameterize the job and don't use the git plugin Ideal solution: git plugin option: "pick branch on 'build now'" would basically do what https://github.com/phemmer/jenkins-git-chooser-build-branches , but inside the git plugin as you suggest ... Sorry to restart a long thread. Are you open to that solution? Should I open a new ticket with the above content (happy to work on it)? Thanks, Andy
            Hide
            markewaite Mark Waite added a comment -

            If you'd like to build a particular git branch, you might try using the git parameter plugin to allow your users to choose the specific branch they want to build.

            Show
            markewaite Mark Waite added a comment - If you'd like to build a particular git branch, you might try using the git parameter plugin to allow your users to choose the specific branch they want to build.
            Hide
            julrich Jochen Ulrich added a comment -

            Maybe I am getting something wrong, but to my understanding, I still have this bug:
            We are using Git Flow and when finishing a release, it results in the following history:

            ---- release/1.0.0
                \
            -----* master & tag/1.0.0
                  \
            -------* develop
            

            So I would expect that master (resp. tag/1.0.0) is built and develop is built since both have different SHA1s due to the merges.
            However, I only get a build for develop.

            Configuration:

            • Branches to build: **
            • Additional Behaviors:
              • Prune stale remote-tracking branches

            Environment:
            Jenkins 1.638
            Git Plugin 2.3.5

            Show
            julrich Jochen Ulrich added a comment - Maybe I am getting something wrong, but to my understanding, I still have this bug: We are using Git Flow and when finishing a release, it results in the following history: ---- release/1.0.0 \ -----* master & tag/1.0.0 \ -------* develop So I would expect that master (resp. tag/1.0.0) is built and develop is built since both have different SHA1s due to the merges. However, I only get a build for develop. Configuration: Branches to build: ** Additional Behaviors: Prune stale remote-tracking branches Environment: Jenkins 1.638 Git Plugin 2.3.5
            Hide
            wojtek Wojtek   added a comment -

            Mark Waite (sorry for reviving the issue but it seems most relevant) I've read the whole issue over and over again, I've tried linked plugin and while it does work there is still remaining issue.

            In principle I would like to have something very simple: I configure branches, each configured branch gets build despite containing already build sha1 (similarly to what's happening when you have only one branch - it's build regardless if the tip sha1 has already been build). Mentioned plugin solves it as it will trigger the build of all configured branches, but… only the first configured branch will get build:
            After filtering out what's already been built: []
            After exploding branches: []
            Nothing seems worth building, so falling back to the previously built revision:
            So I've tried to tinker a bit with the plugin and force it to simply return both branches, but this backfired in a bit unexpected way - as git-plugin uses sha1 to track what was already build it resulted in constantly spawning jobs.

            If I read it correctly there is no way to distinguish it currently from the strategy plugin - is that correct?

            I investigated a bit more and it looks like git-plugin only schedules jobs (vide hudson/plugins/git/GitSCM.java:1018) but then the new build does the same checking… and previous observation applies (that from the strategy it's impossible to make a sane distinction).

            I know that you are reluctant to change it (see your comment on 2014/Sep/05 3:27 PM) but it would be nice if it would be possible to somewhow make it at least optional or available through strategy. If you think this could be done through strategy could you make a suggestion how to approach it? I think more people would be interested in something as simple as "build all configured branches when build is triggered ignoring sha1 checking".

             

            Show
            wojtek Wojtek   added a comment - Mark Waite (sorry for reviving the issue but it seems most relevant) I've read the whole issue over and over again, I've tried linked plugin and while it does work there is still remaining issue. In principle I would like to have something very simple: I configure branches, each configured branch gets build despite containing already build sha1 (similarly to what's happening when you have only one branch - it's build regardless if the tip sha1 has already been build). Mentioned plugin solves it as it will trigger the build of all configured branches, but… only the first configured branch will get build: After filtering out what's already been built: [] After exploding branches: [] Nothing seems worth building, so falling back to the previously built revision: So I've tried to tinker a bit with the plugin and force it to simply return both branches, but this backfired in a bit unexpected way - as git-plugin uses sha1 to track what was already build it resulted in constantly spawning jobs. If I read it correctly there is no way to distinguish it currently from the strategy plugin - is that correct? I investigated a bit more and it looks like git-plugin only schedules jobs (vide hudson/plugins/git/GitSCM.java:1018) but then the new build does the same checking… and previous observation applies (that from the strategy it's impossible to make a sane distinction). I know that you are reluctant to change it (see your comment on 2014/Sep/05 3:27 PM) but it would be nice if it would be possible to somewhow make it at least optional or available through strategy. If you think this could be done through strategy could you make a suggestion how to approach it? I think more people would be interested in something as simple as "build all configured branches when build is triggered ignoring sha1 checking".  
            Hide
            markewaite Mark Waite added a comment -

            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.

            Show
            markewaite Mark Waite added a comment - 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.
            Hide
            wojtek 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)

            Show
            wojtek 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)
            Hide
            markewaite Mark Waite added a comment -

            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.

            Show
            markewaite Mark Waite added a comment - 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.
            Hide
            bradknowles Brad Knowles added a comment -

            Mark Waite – Okay, can you do the above?  Because otherwise the git plugin is kinda broken for us right now.

            Show
            bradknowles Brad Knowles added a comment - Mark Waite – Okay, can you do the above?  Because otherwise the git plugin is kinda broken for us right now.
            Hide
            markewaite Mark Waite added a comment -

            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.

            Show
            markewaite Mark Waite added a comment - 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.

              People

              Assignee:
              ndeloof Nicolas De Loof
              Reporter:
              apaku Andreas Pakulat
              Votes:
              22 Vote for this issue
              Watchers:
              22 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: