Deprecate support for non-configured ruby projects #778

Closed
g2p opened this Issue Nov 27, 2012 · 14 comments

Projects

None yet

5 participants

@g2p

It's not documented anymore, but Travis has implicit support for ruby projects that don't have a .travis.yml file. That support has unintended consequences that are undesirable. For example, branches that don't contain a Rakefile will trigger failed builds.

Such support should be clearly deprecated. This would create an "explicitly configured" project status. Travis should consider a new project unregistered until the first time it sees a .travis.yml file in a push notification. From that point on, the project is marked "explicitly configured", and only push notifications that contain a .travis.yml should be built. Projects that have been successfully built without a .travis.yml file in the past may be grandfathered in, but should be converted to "explicitly configured" projects the first time Travis receives a push notification containing a .travis.yml file.

@roidrage
Travis CI member

Thanks for the suggestion. I can see the merit in leaving more up to the user to make more informed decisions about what should be built and what shouldn't, and more importantly, how it should be built.

We're aware that this can be the cause of confusion, but your idea has wider implications in general. It raises the entrance barrier of people getting set up on Travis significantly if we don't at least try to build their project without requiring further manual intervention. The ease of setting up a project on Travis would be somewhat compromised in my view.

What is a possibility is that we guess the project language based on the information provided to us by GitHub as part of the push payload and try to take the appropriate steps from there.

This doesn't solve the issue with branches being built that don't have a .travis.yml yet, and we're still thinking about a better solution for that. Suggestions and alternatives to ignoring anything that doesn't have a .travis.yml set up are more than welcome.

@g2p

Guessing based on the language opens the door to unintended consequences again.

A good way to keep the barrier to entrance low after the deprecation would be to propose an auto-generated .travis.yml file at the time someone registers a project. The language can be immediately picked up from the github api without harm, because committing the travis file would be subject to user confirmation.

Suggestions and alternatives to ignoring anything that doesn't have a .travis.yml set up are more than welcome.

Since your default runner seems to be rake, ignoring branches that don't have either a .travis.yml or a Rakefile comes to mind.

@svenfuchs
Travis CI member

@g2p, could you remind me what exactly the issue is with having a .travis.yml file on all branches? Anyone else? Just wondering :)

@roidrage
Travis CI member

If a user needs to refine language choice they can do so via the language setting in their .travis.yml at any time. The idea of proposing one when the project is set up sounds reasonable. It would make a good addition to us trying to get a build running without one, even when it fails the first time around.

@g2p

@svenfuchs See my first comment on #414.

@svenfuchs
Travis CI member

@g2p thanks!

@roidrage
Travis CI member

@g2p By the way, the badge supports you specifying a branch to reference. You can add it as a parameter when embedding your badge: just add ?branch=master as a parameter and it will only reflect the master branch's build status.

@g2p

To be absolutely clear, the idea of a pre-built, user-confirmed .travis.yml was not meant as a complement to any kind of build-time autodetection, but as a substitute. I opened this ticket explicitly to get rid of the guesswork.

Here are the reasons I am opposed to DWIM guesswork:

  • Users become reliant on implicit behaviour. Tweaking this behaviour (for example, enhancing the language detection heuristic or updating the implicit test runner) breaks some users, creates a support workload, or ends up being avoided altogether.
  • Users need to take active action to work around those heuristics. For example, they need to create a file to tell Travis to do nothing. (In this case, ironically, opt-out, which should be the default, is an expensive action that require a special file to be present in all branches). This can happen at any time, months after Travis was last configured, and Travis documentation won't be fresh on the user's mind.
@roidrage
Travis CI member

@g2p we understand the reasons you opened this issue, and we're happy to consider some of the alternatives you suggested.

We do have ideas, as outlined above, on how to improve this situation on our end, but they may or may not be exactly what you're asking us to do. The user's experience is very important to us, and making him work more (even if it seems to be more more work for the user to change things after we've tried for the first time in your eyes) lessens the first-user experience in our view.

We might allow for better selection of things to build and not build in the future, that are independent of the .travis.yml file, but we haven't come to a good decision yet on how it could work.

@nevik

@roidrage, Re: [First] User exprience -- I'd like to point out that anyone who doesn't have the default ruby&rakefile build setup has to jump through quite some hoops (and, as mentioned elsewhere, the docs are missing a collection of .travis.yml examples). You guys know better than me how many users of which languages you have, but from a very subjective point of view, I feel unduly disadvantaged by this preference of ruby projects ;)

@henrikhodne
Travis CI member

It's now possible to mark so branches without a .travis.yml is not built at all, which I think fixes part of the reason why this was opened.

@roidrage
Travis CI member

Probably relevant to #1201?

Overall, I think we could consider not running Ruby commands by default for anything.

@henrikhodne
Travis CI member

@roidrage I was just about to link to that too.

I think having no "default commands" if no language is specified would be a good idea.

@roidrage
Travis CI member

Closing this issue for now, as we have no immediate plans to add this feature.

Should we add it to the roadmap eventually, we'll make sure to update this ticket.

@roidrage roidrage closed this Jul 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment