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

No Build Without Changes, Anymore

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      In V2.3.5 of the git plug-in polling without detecting changes caused a build to run. With V2.3.6 and later this is no longer true.

      We think the issue that changed this was:
      https://issues.jenkins-ci.org/browse/JENKINS-29066

      This, however, is a problem now.

      We host our Git repos on Bitbucket (former Stash). Sometimes, we have to invoke "Trigger Build" even when there were no changes pushed to the Git repos. Since that trigger causes a polling for changes, this has no effect anymore with a version newer than V2.3.5.

      Why Do We Need This, Anyway?

      Build results can depend on external systems. If external systems are not available or not correctly configured, the build results are Failed. Now, if we fix those external systems problems, we want to just re-trigger the job to rebuild again.

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment -

            I don't see how we can satisfy the larger community of users who expect polling to behave the way it was described in the original post from Kohsuke (build only when changes are detected) and how you've asked that it behave (build every time polling happens, even if there was no change detected).

            If you intend to build on a schedule, even if things have not changed, then couldn't you use the existing scheduled build facility to schedule that build?

            Alternately, couldn't you use the "build now" link (or the authenticated version of that which will allow you to launch a build even if no changes are detected)?

            Show
            markewaite Mark Waite added a comment - I don't see how we can satisfy the larger community of users who expect polling to behave the way it was described in the original post from Kohsuke (build only when changes are detected) and how you've asked that it behave (build every time polling happens, even if there was no change detected). If you intend to build on a schedule, even if things have not changed, then couldn't you use the existing scheduled build facility to schedule that build? Alternately, couldn't you use the "build now" link (or the authenticated version of that which will allow you to launch a build even if no changes are detected)?
            Hide
            i_more Ingo Mohr added a comment -

            Mark,

            Thanks for the quick answer.
            We'll (have to) check the other alternatives. Thx for advice.

            If more users should request the "build anyway" behavior, maybe there's a way to add a config option for this...

            Show
            i_more Ingo Mohr added a comment - Mark, Thanks for the quick answer. We'll (have to) check the other alternatives. Thx for advice. If more users should request the "build anyway" behavior, maybe there's a way to add a config option for this...
            Hide
            georgi0 Nick George added a comment - - edited

            I'm another user who would like the feature of building for commits that have already been seen. I use the SkullCandy git workflow on Puppet repositories, and it involves merging from a feature branch successively into DEV, then TEST/QA, then PRODUCTION. Because my changes have already been built when I merged into my DEV branch, when I subsequently merge into QA and then PRODUCTION, the Git plugin will refuse to "build" my code. 

            Having a configuration option that says something along the lines of "build even for commits that have already been built against" would be fantastic. 

            Show
            georgi0 Nick George added a comment - - edited I'm another user who would like the feature of building for commits that have already been seen. I use the SkullCandy git workflow on Puppet repositories, and it involves merging from a feature branch successively into DEV, then TEST/QA, then PRODUCTION. Because my changes have already been built when I merged into my DEV branch, when I subsequently merge into QA and then PRODUCTION, the Git plugin will refuse to "build" my code.  Having a configuration option that says something along the lines of "build even for commits that have already been built against" would be fantastic. 
            Hide
            markewaite Mark Waite added a comment -

            Nick George, Stephen Connolly has envisioned the preparation needed to eventually allow tags to be built, even if they are pointing to a commit which has already been built. Do you apply a tag when you merge into QA and into PRODUCTION?

            Also, can you explain how you're merging into QA and into PRODUCTION without a merge commit?

            Show
            markewaite Mark Waite added a comment - Nick George , Stephen Connolly has envisioned the preparation needed to eventually allow tags to be built, even if they are pointing to a commit which has already been built. Do you apply a tag when you merge into QA and into PRODUCTION? Also, can you explain how you're merging into QA and into PRODUCTION without a merge commit?
            Hide
            georgi0 Nick George added a comment -

            Thanks Mark, 

            Now that was a quick response!

            I do not currently add at tag when committing to QA or PROD, but could potentially look into doing it. 

            I have found with GIT that if DEV, QA and PROD all have the same history and you merge from a feature branch into all three, you don't get three different merge commits, but one - so they all end up with exactly the same history (again). 

            Cheers, 
            Nick

             

             

            Show
            georgi0 Nick George added a comment - Thanks Mark,  Now that was a quick response! I do not currently add at tag when committing to QA or PROD, but could potentially look into doing it.  I have found with GIT that if DEV, QA and PROD all have the same history and you merge from a feature branch into all three, you don't get three different merge commits, but one - so they all end up with exactly the same history (again).  Cheers,  Nick    

              People

              • Assignee:
                Unassigned
                Reporter:
                i_more Ingo Mohr
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: