Add 'head_branch' to GitHubChecksRerunActionCause
jgedarovich opened this issue · 1 comments
Feature Request
Add the check_suite[head_branch] value of the check_run payload to GitHubChecksRerunActionCause.
Dependencies
It depends:
Potentially /org/kohsuke/github depending on if the jackson shim dep over the payload does not provide what is necessary to access the check_suite[head_branch] already. Or if org.json.JSONObject is acceptable/performant enough - none.
Context/Background
When working with freestyle jobs that use the git plugin for SCM - we've found git fetch too slow when including too wide of a refspec, and take the tooltips recommendation of specifying a single branch.
In our case - we're trying to setup jobs that trigger for every change to a non draft pull request. Using generic webhook trigger we've been able to achieve that - by filtering over they payload and only triggering jobs that are non draft. Additionally - we're able to pull out the branch name - so that we can pass that into a parameter of the job - so that the git SCM plugin can use it for the refspec to only fetch changes for that PR (even the refspec for just PR's takes exceptionally long to fetch in the repository in question).
This setup has worked well for us with one exception: the re-run button that appears next to the failed status checks in the github UI is not compatible on it's own to filling out the parameter to our job that is normally filled in by the generic webhook trigger. The result is that the SCM refspec that refers to that parameter is either blank if no default or forced to use a default value (again - too wide is unexceptably slow).
When researching this issue we noticed that the plugin actually receives the full re-run request payload from github, which includes the head_branch info we need in order to fill in the parameter value of our jobs - however - the only information that is added to the Cause is the requesting user.
Armed with this information we setup a POC fork of this plugin to add the head branch to the Cause - which we then validated worked! We then took it a step further and were able to use the envinject plugin to pull the value out of the Cause and populate the parameter, SO THAT re-runs used the intended refspec - built the correct branch and reported the status correctly!
should be ok, if you can provide a PR with tests