Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to specify branches in the build matrix #2778

Closed
thedrow opened this Issue Sep 10, 2014 · 10 comments

Comments

Projects
None yet
5 participants
@thedrow
Copy link

thedrow commented Sep 10, 2014

This is useful for example if I want to build only the python3 branch with Python 3.x and PyPy3.
I encountered this use case with: https://github.com/chtd/psycopg2cffi where Python 3 support has not been added to the mainline yet but we should still test it for the relevant branch that provides support for Python 3.

@roidrage

This comment has been minimized.

Copy link
Contributor

roidrage commented Sep 10, 2014

You can have a different .travis.yml in your separate branches, allowing for different configurations based on the branch, no?

@thedrow

This comment has been minimized.

Copy link
Author

thedrow commented Sep 10, 2014

I'm not sure. I can't find the documentation about it.
Parhaps it is simply a documentation issue.

@roidrage

This comment has been minimized.

Copy link
Contributor

roidrage commented Sep 10, 2014

You can have differently laid out .travis.yml files in your separate branches to set different configuration settings to try things out, so that should be worth trying out for your use case.

@roidrage

This comment has been minimized.

Copy link
Contributor

roidrage commented Sep 11, 2014

I'm closing this as the branches option in the matrix would increase complexity of the file and its format, and having different .travis.yml files per branch seems like a reasonable alternative solution.

@roidrage roidrage closed this Sep 11, 2014

@thedrow

This comment has been minimized.

Copy link
Author

thedrow commented Sep 11, 2014

But I can't find the documentation about it.

@roidrage

This comment has been minimized.

Copy link
Contributor

roidrage commented Sep 11, 2014

When you're working on a branch, simply modify the .travis.yml to suit your needs for this specific branch. Every build uses the .travis.yml relevant to this commit, so you can modify it to have different Python versions, different settings in there.

@untitaker

This comment has been minimized.

Copy link

untitaker commented Mar 12, 2016

I think I need this feature to have a different build matrix for pull requests and master pushes.

The full build matrix includes about 40 jobs -- just spinning that many VMs up takes up a serious amount of time. I'd like to give the PR author quick feedback using the stripped down testsuite (which is only one job), while keeping the master branch running on the full testsuite.

@lasote

This comment has been minimized.

Copy link

lasote commented Mar 9, 2017

For a regular workflow with branches in Github is not an option to maintain different .travis.yml files in different branches, you will be merging and solving conflicts in every feature, release and hotfix branches.
Why don't you enable something more dynamic than a `travis.yml' to describe the build matrix? A ruby/python script would be nice and simpler.

bors added a commit to rust-lang/rust that referenced this issue Jul 18, 2017

Auto merge of #43287 - kennytm:travis-ci-adjustments, r=alexcrichton
Change Travis CI job order.

Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`.

1. Move the `$ALLOW_PR` image to the top, so pull requests will start testing as immediately after the build is started. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled.

2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work).

3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below.

4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).

(IMO `$SKIP_BUILD` should not even exist: those irrelevant jobs should not start at all, but that would require travis-ci/travis-ci#2778 which has been rejected)

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jul 18, 2017

Rollup merge of rust-lang#43287 - kennytm:travis-ci-adjustments, r=al…
…excrichton

Change Travis CI job order.

Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`.

1. Move the `$ALLOW_PR` image to the top, so pull requests will start testing as immediately after the build is started. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled.

2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work).

3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below.

4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).

(IMO `$SKIP_BUILD` should not even exist: those irrelevant jobs should not start at all, but that would require travis-ci/travis-ci#2778 which has been rejected)
@kennytm

This comment has been minimized.

Copy link

kennytm commented Sep 16, 2017

This feature is now supported via conditional jobs, by using the if entry inside matrix.include. For instance, OP's .travis.yml may be written as:

matrix:
  fast_finish: true
  include:
    - python: 2.6
    - python: 2.7
    - python: 3.2
      if: branch = python3
    - python: 3.3
      if: branch = python3
    - python: 3.4
      if: branch = python3
    - python: 3.5
      if: branch = python3
    - python: pypy
    - python: pypy3
      if: branch = python3
@lasote

This comment has been minimized.

Copy link

lasote commented Sep 18, 2017

@kennytm thanks for the example. It was exactly what I needed ;)

sbeyer added a commit to banditcpp/bandit that referenced this issue Oct 30, 2017

Copy conditional-branch logic into .travis.yml
Travis CI is slow at the moment. This showed that it is useful
to exclude whole build matrix entries on certain branches instead
on only letting the script do nothing on those branches (but the
environment/image still has to be spawned and initialized which
takes a lot of time).

The chosen solution is the one mentioned in travis-ci/travis-ci#2778

We kept the logic in the shell scripts though.

brodieG added a commit to brodieG/fansi that referenced this issue Aug 7, 2018

Fix #50: test on 3.1, 3.2, ..., but only on the RC branch
@krlmr turns out that there is a solution to this problem
by using conditional branch builds
travis-ci/travis-ci#2778
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.