An interesting suggestion. This may be put on the product roadmap in the future, but I cannot say with any certainty at this time.
Generally speaking, limiting the concurrency across the builds is a repository-level concern, and not a build-level (and therefore commit-level) concern. Therefore, the information about them should not be put in .travis.yml. If we are to implement this, the configuration will be in the Settings page.
Now, for @tomasfejfar’s use case, there may be a workaround. Not one out of the box, but hopefully a workable one.
What you need is something that acts as a traffic controller that knows more about your build pipeline logic than what we currently offer. If I were to implement your workflow, I would try something like this:
- Split the logic into two parts:
- build and run unit tests
- deploy (to testing, to production)
- The first will be executed by
pushandpull_requestevent types, whereas the latter will be triggered by the API. - Write a web app that acts as a liaison between the first and the second parts, the controller that receives the webhook notification and decide whether or not to trigger the second part. (This app can send an API query to find if there is any build of the second type is running, to aid in deciding.)
I hope this helps.