You can clone with
HTTPS or Subversion.
My situation: I have a branch in my repo which i use for integrating upstream changes (since upstream is not a git repo, that branch basically mirrors the upstream repo); naturally, that branch has no .travis.yml.
Howevery, when I push to that branch (and forget to either disable travis or add [ci skip]), travis tries to build that branch with its built-in defaults (ruby & rake, which fails of course, since it's a C++ project).
If possible, I want to avoid adding a .travis.yml to that branch so I can retain its mirror status. Therefore, it'd be neat to be able to disable building of branches without a .travis.yml -- obviously, this would have to be a setting in the web-ui since it can't be in the .travis.yml.
It has been pointed out to me that a similar issue has been raised in #414 -- I'd still like to revive this because I think that building without a build specification doesn't make much sense.
The easiest solution to this right now is to have a specific .travis.yml on your branches, indeed.
We've been thinking about allowing other means to configure which branches to build or specify build configuration in general, but nothing concrete came out of that so far, so the above is currently your best option.
Since I know neither ruby nor the travis interna, I can't make any suggestion that's more concrete than in my initial post above, at least not right now. Once I have a bit more free time, I'd be happy to sit down with you guys and discuss some alternatives for this on IRC :)
I think it's a good motto to try and keep all build configuration in one place (i.e. .travis.yml), so I'd suggest not allowing any extended build configuration outside of that; but as pointed out by me, several users in the issue linked earlier and by @g2p in #778, there are a number of situations in which it would be much more useful to ignore branches with no .travis.yml :)
+1 for this if it can be done.
It seems that the only way to disable building certain branches is to ensure that every branch contains a .travis.yml file, preferably with at least the same branches config as every other branch.
Basically although branches appears to apply to all branches, it actually only applies to the current branch, to decide whether to build it or not. Including or excluding any branch other than the current one has no effect, because the .travis.yml will be read from that branch (not this one) to decide whether to build it when you push to it.
Therefore I don't think it's useful to define the list of branches to build inside the .travis.yml file. It's especially difficult to keep this file in sync across all your branches. It would be really useful to be able to select which branches to build in the travis web UI.
I created a feature request for moving branch whitelisting/blacklisting to the web UI: #1095.
+1 too, for this if it can be done.
Added .travis.yml file
Copied from master-1.2.x branch to prevent build failures, as 2.0 is
currently not setup for builds.
Why would anyone want to see a failure for their project if they push a branch without .travis.yml file? I don't get it.
+1 for Allow disabling build for branches without .travis.yml
This is in the works and we hope to have some news on it soon :)
@joshk thanks! The sooner the better as this is still blocking Django from using Travis.
@qris we have a feature being deployed next week to fix our current email logic http://about.travis-ci.org/blog/2013-11-19-upcoming-email-notification-policy-change/
Combine it with the .travis.yml change and we should be all ready to welcome Django to Travis :)
@joshk I don't understand this part of the new policy:
"If the commit occurs on a non-default branch, the author and the committer of the commit who are also owners of the repository will be notified."
What does "who are also owners" mean? What if they're not owners? If neither of them are owners, does nobody get notified?
Also, what change is required to .travis.yml? I don't see any mention of that on the new policy page, nor understand how it would work. Aren't we trying to get away from configuring email notifications from .travis.yml?
@qris sorry for the confusing statement, this applies to all team members who have admin or push access to the repo.
This doesn't require any changes to your .travis.yml, this will be the default strategy. Sorry if that isn't clear.
This solves the issue where someone forks a repo, eg. Django, then runs a build for it where the most recent commit is from you, for example. Right now we would email you as we get this info from the git commit info, but now we will check the email address from the git commit against Travis to make sure you are part of a team which has access to that repo, so in the case of a fork, you won't be emailed.
Does that make better sense?
@joshk yes that does make sense, thanks!
+1 to disable build of branches with no .travis.yml file
+1 yes, please disable branches with no .travis.yml file
@joshk any news on this or #1095 ?
We should have something to ship soon.
An option to disable builds without .travis.yml is now available in repository settings: http://blog.travis-ci.com/2014-03-05-repository-settings/
@drogus thanks a lot! <3