Allow repositories to specify where `.travis.yml` should be found

Travis CI Discussions & Feedback Feature Requests
1

I’d like to keep repository free from CI configuration noise.

e.g. Appveyor CI allows to provide an URL to YAML config on project settings in Appveyor GUI.
It’s great also for other reason, as that way I can easily share common config among projects that require same setup.

Is there any way to achieve that with Travis CI? If not, is it somewhere on a roadmap?

2


and

also ask for different locations for looking for the configuration file.

1 Like
3

I would very much like if .travis.yml could be moved to a subdirectory of our choice.

Note that this topic (which we were redirected to from github issues) seems to conflate two different requests:

  • [1] Specify local pathname to travis.yml. Depending how implemented, renaming .travis.yml to travis.yml can be the same feature. (this is my request).
  • [2] Host travis.yml externally (aka possibly set a web url instead of the local pathname), this is what OP requested (I pesonally don’t need this, but it could be seen as an extension of [1]. Arguably [1] without [2] is easier to implement).

Thank you.

4

It would be nice to be able to put the file in .github/travis.yml or allow for a configurable file name in the web UI for a repository.

This would allow for reducing the number of files in the root of the repository, while allowing for easier dealing with per-project quirks related to that.

5

This feature would be very useful for us too. As our project grows, our CI structure and pipeline grows too, and it would be nice to organize everything in a directory, such as ci/travis.yml, ci/script_foo, ci/script_bar, instead of having files scattered in multiple places. :+1:

6

Any update on this feature? I would like travis CI to be triggered only if there are changes in that directory. I followed issue thread #5519 filed by ottok. Any update? or any alternatives to achieve this?

7

This has been a long standarding feature request. If it is hard, what about a symlink from .travis.yml in the root to a file located elsewhere in the repo?

Or an include syntax which could be used to have a very simple .travis.yml at the root which points to one or multiple file located elsewhere in the repo , or better also allow including a URL to resource hosted outside the repo.

1 Like
8

Has anything been done to solve this? I have too many config files which will scare a regular user.

9

+1 My repository allows using of multiple CI (in case contributor wants to use something else) so travis’s configuration in root of repo is pretty annoying… i would like to use ci/ dir…

10

Now it’s possible to import other YAML files into .travis.yml:

This solves the problem of reusing parts that are common for multiple repositories.

11

Let me make a counterargument on this and see if the pros outweigh the cons.

  • (key point) It has become standard practice for many (most?) development tools to have their “root” configuration file in a repository root.
    • this includes standard build tools, lint tools, testing tools, IDEs
    • The reason is this allows those tools to find their instructions
      • unambiguously
      • without imposing any structure requrements on the source tree – thus fit for any and all projects, unlike anything else
      • with zero configuration
  • As a result of the above, this is where a person expects to find all the “entry points” into the codebase. Which allows them to:
    • Instantly learn what they can do with the code
    • Instantly do stuff with the code using standard tools and procedures
      • without the need to scry around looking for ins and outs into the codebase god-knows-where
      • without the need to configure each of those tools to understand the nonstandard project structure
        • which a tool may not even support since that’s extra costs that can be easily avoided if everyone just follows the standard. In that case, access to this tool would be lost for you altogether.
    • As a result, nonstandard stuff placement puts a project at a competitive disadvantage since
      • The current state of affairs in IT is a technological singularity so it’s an absolute must to spend as little time and effort learning non-fundamental stuff as possible
      • as such, having to spent any more time and effort setting up and working with a project than absolutely necessary is wasted time and an unnecessary barrier to entry
        • which is bound to turn a share of prospective contributors away since they would feel that such a blind upfront investment would likely be not worth the result they hope to get and/or that you don’t value their time so are not worth doing business with
        • even for those that do invest enough and manage to set everything up correctly – including yourself, – it’s still a cost that could be avoided

So go ahead, place stuff in random places that only you know of. You will only be wasting your own time, money and opportunities and putting yourself at a competitive disadvantage to projects that don’t.

12

A lot of tools have the option to store configuration files in a subdirectory, and I’d say it’s gaining traction among developers. Popper, for example uses a .config folder for their babel, rollup, eslint, etc configuration files. https://github.com/popperjs/popper-core

This approach makes for a cleaner root folder and, since dev tool configs are alone in their own folder, it makes them easy to find and review.

As of writing, all of my config files are in a .config folder except for my .travis.yml and it would be really nice if I had the option to move it.

13

This means you still have that .config folder in root – and will need to have another one all the same if you use another tool.

I’ve seen .travis.yml in root made into a symlink to a “ci” subfolder.

14

This means you still have that .config folder in root – and will need to have another one all the same if you use another tool.

One .config folder is enough. I’m looking to do what popper has done with multiple files inside their .config folder: .config/travis.yml, .config/babel.conf.json.

15

See my counterarguments above.
Even if a tool uses a subdirectory, you’ll still have at least one root directory entry per tool – because another tool’s author will need to use another subdirectory to avoid conflicts.

So a tool using a subdirectory for configuration doesn’t actually “clean up the root directory” without losing the zero configuration quality as proponents argue. You still need at least one root directory entry per tool – and usually exactly one because a tool doesn’t really need more (anything else it may need can be linked to from this entry).

16

Hello.

But tools don’t seems to have conflict by using a single config directory “the root of the repository”.

Regards.

17

Yes, because the root directory is an implicit standard: it always exists and always in the same place (the current directory as far as tools are concerned). Anything else, all bets are off: you cannot blindly rely on anything else whatsoever to exist within a project’s tree.