You can clone with
Another interesting suggestion that came up when discussing #1094 was to move the branch blacklist/whitelist to the website. Having this information stored in our database means we get rid of the slightly odd behaviour where a branch only follows the .travis.yml file on that branch (see #414/#609).
On the database side this could probably be as easy as a whitelist and blacklist field on the repository table containing lists of branches. Again we need to make a page to put these setting on, see #1094.
This issue supersedes #902 and a fix for it would also fix that issue.
(Travis has been quite a mental paradigm shift for me. I would've expected email notifications to be controlled on a per-user basis through the website, for instance.)
+1 for this one!
Added .travis.yml file
Copied from master-1.2.x branch to prevent build failures, as 2.0 is
currently not setup for builds.
I second this. Out of 3 Travis CI builds that are run for my fork, on average 2 are unwanted. Because I am a contributor, I cannot change travis.yml or commit messages some branches, typically master. These builds are guaranteed to fail, so they are of no use to me.
I use customized scripts for my dev branch. That is the only build I want and pay attention to.
Think of how much server time Travis CI could save, if no unwanted builds were ever run
to @arstrube for whipping out the econ arguments! :D
This is definitely needed. Right now I have to create a new repository with a single branch just because of this.
And now I have a mess of temporary and non-existent branches reported as failed even though they don't have a .travis.xml file, or aren't even there any more.