Hi
Since it is now (In the 1.7 RC) possible to “split” a repository into multiple configurations using regex filters for files on the Git repository trigger, this means there are new problems also. I have a repository that is split into two parts, one is the backend, the other one is a web client. These two have different configurations that builds each part separately based on which files have been modified.
However this does not cope well with Pull requests, since the pull request is rebuilt when anything changes in the two branches that are to be merged. So if I do a pull request between a feature branch that only has changes to web client and develop, and the develop gets a new commit with backend changes, this will trigger both configurations, which is fine. However this means that one of the builds might fail, and the other succeed, which also is fine. The problem lies within the Event handler for updating GitHub status, that first updates status of pull request to Failed for the one build that failed, but then when the other build finishes successfully to Succeeded, overwriting the Failed status.
My solution to this problem would be to allow us to specify the “Context” variable in the API call from the Event Handler settings, since GitHub has support for multiple checks on pull requests:
https://developer.github.com/v3/repos/statuses/
https://github.com/blog/1935-see-re…tus-checks
This way I could have both configurations with an own context and see which one has failed. Is this something you would want to implement?
TL;DR; Allow us to specify multiple “context” instead of only using ‘default’ in “GitHub update status” event handler.
//Walliski
Hi Walliski,
Thanks for requesting this. It should be simple enough to add. I’ll see if we can include in the next build.
Sounds good!
When driving to work I started thinking about this again though. When you push a change to the feature branch, both the feature branch and the pull request branch would be built from the same configuration, thus overwriting the status… So there would have to be some way to specify which events to fire based on which trigger has started the build or something? Or maybe be able to use variables in the context and set these from the trigger, having two triggers, one for pr branches, one for others… What do you think?
//Walliski
Hi Walliski,
The context field will support expressions so you can used variables set by triggers or based on other build expressions. We may also include Conditions tab for Event Handlers in the future where you add a set of expressions which must be true before the handler runs.