.travis.yml is no more alien to your project’s codebase than a
.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. https://github.com/matthew-brett/multibuild#to-use-these-scripts) 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.