Update / status report: we did check the supported webhooks to see whether we have to add additional components/logic to get all the relevant info (time consuming) required to determine the file change list.
Unfortunately, after checking only GitHub and Bitbucket, only GitHub code push webhooks include the list directly. Bitbucket does not include the file change list in either in code push nor in PR webhooks, and GitHub does not include it in PR webhooks.
This means that to get the changed files list a new component should be added to the existing system, which receives the webhook but will have to delay starting the build (or not starting it) until it can retrieve the file change from the related service, and only perform the trigger map check after that.
The issue with this approach is:
- It might significantly increase the webhook processing time. The trigger map check can only be performed after bitrise.io performs an API call to the relevant service (GitHub, Bitbucket, …) to retrieve the file change list. If those APIs are slow for any reason, or even worse have issues (causing retries for the API calls) that can slow down the whole processing and build starting quite a bit.
- It requires an additional API call, specific for the service, for every supported service and webhook type.
It requires API authentication, meaning the API call can only be performed if you connect your GitHub/Bitbucket/… account to your Bitrise.io account (which is not a requirement for the current webhook system, only for pushing back build status to the service, but builds can start without any connected account just by processing the webhook).
Bitrise.io can’t return a precise response for the webhook like it does right now, only after it could retrieve the file change list. If it takes too long (API call timeout) then this will reduce the debugging options (http://devcenter.bitrise.io/webhooks/troubleshooting/).
This is how the current system works:
GitHub/Bitbucket/... -> webhooks.bitrise.io -> bitrise.io (start build)
And this is roughly how it should work to support file change based filtering:
GitHub/Bitbucket/... -> webhooks.bitrise.io -> bitrise.io -> GitHub/Bitbucket/... (API) -> bitrise.io (start build)
Don’t get me wrong, we don’t reject this #feature-request! It definitely can be done, but will take more time than we hoped. This is simply an update & summary of what we discovered so far.