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

Support for multiple .travis.yml files #3540

cancan101 opened this Issue Apr 1, 2015 · 9 comments


None yet
9 participants
Copy link

cancan101 commented Apr 1, 2015

Is there any plan to support multiple .travis.yml files within one repos? Currently my repos is laid out as:


where s1,... are various microservices. Right now I have to cram all of the settings for all services into the one travis file.

There seems to be a trends toward monorepos such as Google and now Facebook so having the ability to specify different configs within one repos is important.


This comment has been minimized.

Copy link

BanzaiMan commented Apr 1, 2015

I think this has been requested before, though I can't find specific issues.

One problem I see is that we do not know ahead of time where .travis.yml might be, so we need to check out the entire repository before processing the build (or is there a GitHub API calls that allow this inexpensively?).


This comment has been minimized.

Copy link

cancan101 commented Apr 1, 2015

I could not find an existing issue either.

I guess there are a few questions here. Would the user set up in advance each of the subdirectories to build against (and in which to find a .travis.yml or would that be discovered)?

If in advance, then this could be used:
If discovered then there would be something in the root of the repos that points to the list of other .travis.ymls.


This comment has been minimized.

Copy link

humzashah commented May 16, 2015

@BanzaiMan A solution could be to have a base yml where paths of the other ymls (the ones in the sub-repos) will be explicitly set.

@cancan101, I was brought here because I was googling for something similar. I've now spread out my "services" into individual repos that I add to the original project as git submodules. This helps not only to isolate tests, logic, etc. but also to ensure that a test-failure would mean the failure of a submodule and not of the entire project, thereby saving test execution time, amongst other things.


This comment has been minimized.

Copy link

johanatan commented Jul 17, 2015

Is there any alternative to creating submodules for this?


This comment has been minimized.

Copy link

joshk commented Jul 18, 2015

Thank you for opening this issue to discuss the idea.

I'm sorry but I am going to close this issue for the time being as we don't have plans to add multi .travis.yml file support, at least for the foreseeable future.

Have an awesome weekend



This comment has been minimized.

Copy link

roidrage commented Jul 23, 2015

Thank you for your suggestion, but I'm closing this issue for now, as we have no immediate plans to add this feature.

Should we add it to the roadmap eventually, we'll make sure to update this ticket.

@roidrage roidrage closed this Jul 23, 2015

mshenfield added a commit to mshenfield/oss-intro-class that referenced this issue Feb 25, 2017

Added .travis.yml file for python
According to [these](travis-ci/travis-ci#4090) [issues](travis-ci/travis-ci#3540) you can't have multiple build environments for a single project. For now just adding one for the python project.

@schmunk42 schmunk42 referenced this issue Mar 10, 2017


added dockerized test setup #13360

5 of 7 tasks complete

@karllhughes karllhughes referenced this issue Mar 31, 2017


Travis CI improvements #238

0 of 5 tasks complete

This comment has been minimized.

Copy link

therealplato commented Sep 10, 2017

This ticket was one of the first results for my search travis only modified subfolder. Similar to OP i have a monorepo with multiple services and languages. I'd like to find something better than "test every service on every push." Since 2015 has the community come up with a workflow for testing one monorepo service at a time?


This comment has been minimized.

Copy link

CallumHogg commented Sep 18, 2017

@therealplato The best I've come up with for the time being is conditionally running test suites based on the output of git diff e.g. if git diff --name-only HEAD^ | grep "API/"; then npm run test-api; fi so it will only run my API tests when something in the API folder changed.


This comment has been minimized.

Copy link

markeissler commented Nov 2, 2017

Because of this opinion Status badge for each OS of a build (#4623)

We prefer to view a build as a whole, with the status badge being an indicator, and the build's matrix results being the single source of truth. @roidrage

It would be helpful if we could at least use separate .travis.yml files (one for each build target) and then just specify the name of the specific.yml file for a build in the build settings (defaulting to the standard .travis.yml file).

For instance, for a project that targets both macOS and Linux you could have a standard .travis.yml for the Linux build and then also a .travis-macOS.yml for the other build. That way we can accurately provide status badges for different builds.

While it's obviously possible to configure multiple builds in a matrix defined in a single configuration that lumps all of the builds together with a single overall status that workflow clearly doesn't work for everyone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment