Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Won't Do
-
Component/s: git-plugin
-
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
- relates to
-
-
- Closed
-
Activity
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?
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.
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. 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...
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... 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)?
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