Filter git SCM branch in github push #44
Conversation
aserrallerios
commented
Jul 21, 2014
|
plugins » github-plugin #45 SUCCESS |
|
Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests |
|
This would be a really nice feature. I hope someone can review it and merge it soon. |
|
+1 this would be very useful to us as well. |
|
The PR conflicts with a current master branch => could you rebase it? |
There was a problem hiding this comment.
Javadoc is required.
Is there any risk of regressions in other plugins (if somebody declares a GithubTrigger)?
|
@aserrallerios |
5441fbb to
ab0af83
Compare
|
Rebased, and decoupled some concepts. Added some tests for the GitHub - SMC branch matching. I tried to add some tests for the |
|
+1 really missing this feature at the moment! |
|
+1 for this feature |
|
+1 please |
1 similar comment
|
+1 please |
|
+1 please |
There was a problem hiding this comment.
Are you coding from mobile? Why so short width?
|
Am I understanding this PR correctly in that it will filter the branch out of the github webhook push request, so that only the branch that has received a push will be poked? We have a serious issue right now whereby we effectively DoS ourselves due to the number of branches we have and a webhook push causes -every- branch to get considered and poked. If so, any idea when this will get merged in? I did try building it locally (installed oracle JDK7, maven, and did a mvn hpi:hpi per the readme) but the resulting plugin .hpi file did not seem to work - Jenkins did not recognize it correctly. All github references were removed from the config options, and Jenkins complained about incorrect data in the config files. I think it's more likely that I made a mistake in building it than a problem with the PR, though. Happy to try it if I can get a pointer on how to properly build it. |
|
@npaufler |
There was a problem hiding this comment.
Why it hardcoded? What if i want trigger refs/tags, refs/notes?
What do you mean under "-every- branch to get considered and poked"? In general this PR looks not well formed, @aserrallerios proposed PR without referring to any jira issue or any description. |
|
It's quite possible that I'm not understanding this, but if you are interested in scheduling builds only for specific branches, the right thing to do is to set the branch spec in the Git SCM configuration. All this plugin is doing is to schedule a polling, and it's up to the Git plugin to determine if the change pushed is worth the build. There are lots of criteria when it comes to what is considered an interesting change and what is not. We can't add every one of them in this plugin. We've learned that lesson in the Subversion plugin and the Git v1 plugin. |
|
@kohsuke probably penalty is in heavy weight polling check that is called in SCM internals. Of course github plugin can't determine that some job configuration meets build criteria (for example excluded messages and other behaviours), but it can do light filtering, for example by filtering not matched branch specifier configuration. (just a guess) |
|
Btw, @aserrallerios @npaufler could you test this PR #39 ? It changes the way how plugin triggers builds it also deal with branches. I think #39 will be merged in any case because it switches to better API usage. |
|
I'm interested in the feature this PR provides, but it seems fairly complex and inflexible vs the approach of providing values from the push event payload as build parameters, as discussed in JENKINS-24291. I hacked together enough a prototype to verify that exposing such parameters is both doable and enables the results that I'm trying to achieve. If I cleaned the implementation and opened a PR, would such a change be accepted? |
|
@llasram i doubt. Atm trigger do the simple thing - it calls GitSCM poll that then checks whether build should be scheduled. Gitscm contains branch specifier and other features that "filter" == choses branch to build. If you need "filter" branch, then set correct branch specified in gitscm configuration. |
|
Closing as initial author didn't respond to any questions and code is not mergeable anymore for a long time. |
|
Is there any intention on making this work for upcoming versions? Seems like a really useful functionality |
|
Can we please get a working version of this? There are several tickets that have been open since 2014 that apply to this concept. Passing data from the webhook as environment variables would be minimally useful. Either way, having a new project that builds all branches because it has never been built before is pretty useless. I just hit this at work and had a 20minute build job that fired off for some 30 branches because of the number of engineers working... and a brand new jenkins installation. |
|
YOU CAN'T DO IT BECAUSE PUSH TRIGGER IS ONLY KICKS POLLING WITH SEPARATE LOGIC. |
The existing webhook handling code would trigger the GitSCM poll for the default branch regardless of whether or not the target ref of the webhook push event matched the branch specifier of the Job definition. This is problematic and often leads to duplicate builds for the same branch+revision if pushes to other branches happened to occur whilst build(s) were already in progress for that branch. This is because the GitSCM trigger just compares the HEAD revision of any branch matching the branch specifier against the last *completed* build of that branch (ignoring in-progress builds) and schedules a new build for it. The code for this PR is mostly a rebased version of the original changes proposed by @aserrallerios under jenkinsci#44 with some small refinements. Co-authored-by: Albert Serrallé Ríos <[email protected]>
The existing webhook handling code would trigger the GitSCM poll for the default branch regardless of whether or not the target ref of the webhook push event matched the branch specifier of the Job definition. This is problematic and often leads to duplicate builds for the same branch+revision if pushes to other branches happened to occur whilst build(s) were already in progress for that branch. This is because the GitSCM trigger just compares the HEAD revision of any branch matching the branch specifier against the last *completed* build of that branch (ignoring in-progress builds) and schedules a new build for it. The code for this PR is mostly a rebased version of the original changes proposed by @aserrallerios under jenkinsci#44 with some small refinements. Co-authored-by: Albert Serrallé Ríos <[email protected]>
The existing webhook handling code would trigger the GitSCM poll for the default branch regardless of whether or not the target ref of the webhook push event matched the branch specifier of the Job definition. This is problematic and often leads to duplicate builds for the same branch+revision if pushes to other branches happened to occur whilst build(s) were already in progress for that branch. This is because the GitSCM trigger just compares the HEAD revision of any branch matching the branch specifier against the last *completed* build of that branch (ignoring in-progress builds) and schedules a new build for it. The code for this PR is mostly a rebased version of the original changes proposed by @aserrallerios under jenkinsci#44 with some small refinements. Co-authored-by: Albert Serrallé Ríos <[email protected]>
The existing webhook handling code would trigger the GitSCM poll for the default branch regardless of whether or not the target ref of the webhook push event matched the branch specifier of the Job definition. This is problematic and often leads to duplicate builds for the same branch+revision if pushes to other branches happened to occur whilst build(s) were already in progress for that branch. This is because the GitSCM trigger just compares the HEAD revision of any branch matching the branch specifier against the last *completed* build of that branch (ignoring in-progress builds) and schedules a new build for it. The code for this PR is mostly a rebased version of the original changes proposed by @aserrallerios under jenkinsci#44 with some small refinements. Co-authored-by: Albert Serrallé Ríos <[email protected]>
The existing webhook handling code would trigger the GitSCM poll for the default branch regardless of whether or not the target ref of the webhook push event matched the branch specifier of the Job definition. This is problematic and often leads to duplicate builds for the same branch+revision if pushes to other branches happened to occur whilst build(s) were already in progress for that branch. This is because the GitSCM trigger just compares the HEAD revision of any branch matching the branch specifier against the last *completed* build of that branch (ignoring in-progress builds) and schedules a new build for it. The code for this PR is mostly a rebased version of the original changes proposed by @aserrallerios under jenkinsci#44 with some small refinements. Co-authored-by: Albert Serrallé Ríos <[email protected]>
The existing webhook handling code would trigger the GitSCM poll for the default branch regardless of whether or not the target ref of the webhook push event matched the branch specifier of the Job definition. This is problematic and often leads to duplicate builds for the same branch+revision if pushes to other branches happened to occur whilst build(s) were already in progress for that branch. This is because the GitSCM trigger just compares the HEAD revision of any branch matching the branch specifier against the last *completed* build of that branch (ignoring in-progress builds) and schedules a new build for it. The code for this PR is mostly a rebased version of the original changes proposed by @aserrallerios under jenkinsci#44 with some small refinements. Co-authored-by: Albert Serrallé Ríos <[email protected]>
The existing webhook handling code would trigger the GitSCM poll for the default branch regardless of whether or not the target ref of the webhook push event matched the branch specifier of the Job definition. This is problematic and often leads to duplicate builds for the same branch+revision if pushes to other branches happened to occur whilst build(s) were already in progress for that branch. This is because the GitSCM trigger just compares the HEAD revision of any branch matching the branch specifier against the last *completed* build of that branch (ignoring in-progress builds) and schedules a new build for it. The code for this PR is mostly a rebased version of the original changes proposed by @aserrallerios under jenkinsci#44 with some small refinements. Co-authored-by: Albert Serrallé Ríos <[email protected]>
The existing webhook handling code would trigger the GitSCM poll for the default branch regardless of whether or not the target ref of the webhook push event matched the branch specifier of the Job definition. This is problematic and often leads to duplicate builds for the same branch+revision if pushes to other branches happened to occur whilst build(s) were already in progress for that branch. This is because the GitSCM trigger just compares the HEAD revision of any branch matching the branch specifier against the last *completed* build of that branch (ignoring in-progress builds) and schedules a new build for it. The code for this PR is mostly a rebased version of the original changes proposed by @aserrallerios under jenkinsci#44 with some small refinements. Co-authored-by: Albert Serrallé Ríos <[email protected]>
The existing webhook handling code would trigger the GitSCM poll for the default branch regardless of whether or not the target ref of the webhook push event matched the branch specifier of the Job definition. This is problematic and often leads to duplicate builds for the same branch+revision if pushes to other branches happened to occur whilst build(s) were already in progress for that branch. This is because the GitSCM trigger just compares the HEAD revision of any branch matching the branch specifier against the last *completed* build of that branch (ignoring in-progress builds) and schedules a new build for it. The code for this PR is mostly a rebased version of the original changes proposed by @aserrallerios under jenkinsci#44 with some small refinements. Co-authored-by: Albert Serrallé Ríos <[email protected]>
The existing webhook handling code would trigger the GitSCM poll for the default branch regardless of whether or not the target ref of the webhook push event matched the branch specifier of the Job definition. This is problematic and often leads to duplicate builds for the same branch+revision if pushes to other branches happened to occur whilst build(s) were already in progress for that branch. This is because the GitSCM trigger just compares the HEAD revision of any branch matching the branch specifier against the last *completed* build of that branch (ignoring in-progress builds) and schedules a new build for it. The code for this PR is mostly a rebased version of the original changes proposed by @aserrallerios under jenkinsci#44 with some small refinements. Co-authored-by: Albert Serrallé Ríos <[email protected]>
The existing webhook handling code would trigger the GitSCM poll for the default branch regardless of whether or not the target ref of the webhook push event matched the branch specifier of the Job definition. This is problematic and often leads to duplicate builds for the same branch+revision if pushes to other branches happened to occur whilst build(s) were already in progress for that branch. This is because the GitSCM trigger just compares the HEAD revision of any branch matching the branch specifier against the last *completed* build of that branch (ignoring in-progress builds) and schedules a new build for it. The code for this PR is mostly a rebased version of the original changes proposed by @aserrallerios under jenkinsci#44 with some small refinements. Co-authored-by: Albert Serrallé Ríos <[email protected]>