ghprb-plugin
ghprb-plugin copied to clipboard
jenkinsci
perform action on PR close
It would be great if the ghprb plugin would react to a PR close(/merge) and be able to perform an action.
example: I want to deploy a test environment every time a PR is made, which is totally possible, however when the PR is closed I would like to be able to destroy that test environment.
I've the same scenario as described. Is this possible with this plugin? @paulczar have you found any workaround for this?
I ended working around this manually with a github webhook and a custom job
+1
As an aside @gvilarino if you still happen to have this custom hook and job operating, care to elaborate some? This is something I sort of really, really need.
@tykeal yeah! So I use a github webhook that triggers a webtask, that munches github's payload and triggers a jenkins job with the params I need.
You can see (and improve!) the code for the webtask here (you might want to remove the rollbar dep).
I think this is outofscope of the plugin, no? You could simply configure a new build which reacts on the merge.
Does this make sense to you? Thank you!
@bjoernhaeuser the problem with that is that this plugin triggers builds with different parameters than say the GitHub Plugin itself. The point behind the request is that there is a webhook condition that this plugin should be passing on / allowing you to trigger based off of that isn't being handled.
I believe that folks want to see this plugin become feature comparable with the Gerrit Trigger plugin for Gerrit changes. Not handling close / merge changes mean you aren't comparable.
@tykeal understood!
What kind of actions would you run? And what parameters are needed and differ from GitHub Plugin?
From my point of view there is no difference between closing a pr and triggering a new build from the commit in master.
My use-case involves creating temporary environments for each pull request. Ideally I'd have a build triggered to clean these up. Waiting for merge on master doesn't give me as much information as this plugin and in turn does not help me identify which environment I'd need to destroy.
I can think of this plugin offering a second trigger (in addition to "Github Pull Request builder") which could be named "Github Pull Request closed". This way, no need to if our way around our use case and we can have two different jobs.
I have the same use case as @Floby (creating temporary environments for each pull request). Triggering closed PRs would solve our problems too.
@Floby @bjoernhaeuser having a second trigger isn't really as good an option IMO, part of our desire is to have this plugin be as 100% comparable to the Gerrit Trigger plugin as possible. We exercise nearly every single option in the Gerrit trigger with the projects that we host that are Gerrit based and because we heavily leverage Jenkins Job Builder for our jobs we're managing in excess of 7000 jobs across our current environments.
In many some cases we have verify / merge jobs that are literally the same job except artifacts are pushed to the artifact storage if it's a merge job. So having the trigger just be able to support Merge directly without having to have a completely different trigger plugin / trigger defined would be optimal.
Ideally, the merge trigger would also support comment triggering just like the open / updated PR triggering currently does as well. This is also a feature that we strongly use to trigger particular types of events in our build environment.
If you're curious as to what all we do, our global-jjb templates are what power a good portion of the jobs in our environment and they're completely open and available on our GitHub mirror here: https://github.com/lfit/releng-global-jjb or direct from the source here: https://gerrit.linuxfoundation.org/infra/#/admin/projects/releng/global-jjb
Any solution in these past 5 years? Alternative solutions are also fine.. Thanks
Yeah we have this same problem related to temporary environments that are created that we use to verify PRs before merging - we deploy as part of the pipeline - run tests - and then we would like that environment to stay up whilst the PR is open so that additional changes can be pushed to it, and it can be used as a demonstration environment before the PR is closed.
