Feature Request: Limit concurrent builds by branch / tag / PR

It would be great to be able to limit concurrent builds by branches, tags, and pull requests

For example:


  pull_request: 0 # unlimited
  branch: 0  # unlimited
  tags: 1

Name specific branches

  pull_request: 0 # unlimited
    - master: 1  # Limit to 1 for the master branch only
    - "*": 4  # All other branches limited to 4
  tags: 1

A specific use case would be Continuous deployment for commits to master, or deployment on tag/release

Ref.: https://github.com/travis-ci/travis-ci/issues/6547
Posting here because: https://github.com/travis-ci/travis-ci/issues/10026#issuecomment-443386988

Ideally it would allow “locking” stages. We have three stages:

  • build and run unit tests (runs everywhere, takes ~ 5 minutes)
  • deploy to testing and run integration tests in the actual server environment (tags & master, takes ~ 1h)
  • deploy to production (master only, takes ~ 10minutes)

Ideally we would have the 2nd and 3rd stage locked to only one instance, but keep the 1st unlimited. That would allow us to build PRs, even though someone just merged master and there is at least an hour build running.

What you actually want is to queue deploy requests for your test environment. Which is not limited to just a number of homogeneous environments, so the requested feature is not a very flexible solution.

A flexible solution would be to make jobs wait for an external event before starting – e.g. the same way GitHub’s check status reports work. (Travis would send a build request to a webhook in your environment which would queue it and report back when it’s ready.)

I’m not sure how good of a fit this is for Travis CI. Here, you are supposed to run all the functionality on the CI’s machine. Maybe an on-site installation of Travis CI with a custom worker type representing your test environment would be a better fit for your workflow.

Not really. Even if I were to queue the actual deploy I still need to sync between my deployment service and Travis. That will be source of bugs and unnecessary complexity.

  • build started for [1]
  • “1st stage” of [1] finished
  • deploy [1] to testing queued and running
  • build started for [2]
  • “1st stage” of [2] finished
  • deploy [2] to testing queued
  • deploy [1] finished
  • < here it must not start deploying to testing for [2] >
  • notify travis that testing env is finished and it’s time to run “2nd stage” for [1]
  • run test on deployed testing server for [1]
  • finished “2nd stage” for [1]
  • only now can deployment to testing for [2] start

Building some notification framework to talk between Travis and the Deploy process would be a big undertaking. While having a function to make something a “critical section for the repo” (allowing it to run only in one thread for the whole repo) is a relatively contained feature that affects only Travis and does not require any synchronization with outside services.

I would agree that this might not be part of continuous integration. But it certainly is a part of continuous deployment :slight_smile: And I think that it’s actually a great fit for Travis!