Hi,
I can’t find a way to create a job using travis-ci.com UI. I’m being told to add a .travis.yml file in my project but I don’t want to add something that is not source code related to my project - it makes sense, I don’t want to have to commit something when I need to change my quality pipeline, obviously.
I was able to trigger a custom build but not to save it for later use. Did I miss something?
Eric.
You did not. If you want persistent configurations, please use .travis.yml.
But then I create a dependency between my project and Travis CI and I have to commit changes to my project that are not related to the final product. For example, I shouldn’t have to commit anything to add a new version of Node.js to my test job.
Since its inception, Travis CI has taken the industry-standard “configuration as code” paradigm to heart. As a result, we think .travis.yml belongs to your repository.
You can trigger builds with API, and we will keep the records for you, but it is up to you to manage what changes you make to those API payloads.
.travis.yml is no more alien to your project’s codebase than a Makefile.am, .gitignore or e.g. a linter configuration – the files whose primary purpose is to support the development process rather than be used by the end user directly.
That said, if you release tarballs, you can very well omit .travis.yml from them just like other above-mentioned stuff that’s not strictly required to compile/run the product. But since it contains valuable information (e.g. which environments that version of the product was officially tested in – thus officially supports), that may or may not be a good idea.
Using your example,
For example, I shouldn’t have to commit anything to add a new version of Node.js to my test job.
this change does belong in the codebase because it’s a part of your test configuration. You need to keep this kind of information somewhere, don’t you, and it is tied to a specific version of your code, so why not alongside it?
Actually, I have seen projects (e.g. GitHub - matthew-brett/multibuild: Machinery for building and testing Python Wheels for Linux, OSX and (less flexibly) Windows.) that suggest creating a separate repository for CI and adding your main codebase as a submodule. But that is extremely inconvenient because it doesn’t allow you to, well, do CI – automatically check your code at every commit – in a straightforward way. So in my practice, no-one followed that advice.