You can clone with
HTTPS or Subversion.
It seems odd that if someone goes to see the build status at the root of the project they see the potentially failed build of a random PR. Unmerged PRs may never make their way into a project and should not be considered part of the project's build in the "Current" tab.
I thought there was a related ticket from this, but I can't find it.
Funnily enough, we talked about this exact issue 10 minutes before it popped up here. There was mostly consensus that it is confusing and that pull requests shouldn't affect the master build status. It doesn't require major changes, but involves discussing some more issues around the build status, as it affects several areas of Travis.
Glad to hear the consensus ruled in my favor :)
Keep up the great work guys.
can this also be fixed for branches maybe? i know you can specify the branch when requesting the build status image,
but for projects which are using branches on a regular basis, it's kind of annoying to always change the link.
ps. this is probably a totally unrelated "issue" and not that easy to solve, but i would like to hear your thoughts on this.
always change the link? i'm confused. this change doesn't have much to do with the build status image.
maybe i got it wrong, but let me explain.
a) if you don't specify a branch in the build status image link, you'll always see the build status of the master branch, right? even if you're looking at the readme of a different branch. so if master fails and your branch passes, the readme still displays a failing build status.
b) now if you specify the branch in the build status image link instead, you have to remember to change that link every time you create a new branch to display the proper build status.
this really belongs into a different ticket, but how would travis get to know on which branch the readme is where the image tag's url is used?
well, the image request includes the request uri and other information about the origin of the request, right?
i'm not sure if github's url schema always makes it easy to extract the branch, but it might be worth a try.
this really is another issue, so i can open a new one if you think it's worth it.
I think #567 is the related ticket @steveklabnik was mentioning.
We're seeing this on Sunspot.
for fixing this :)
Is this fixed? Can we close this to ticket?
(…he said and closed it. Oops)
Any progress on this? It's still an issue.
Seems to have gone cold? Was this fixed and just never closed?
I think maybe travis-ci/travis-core#318 would fix this?
So I'm removing the Travis badge from Bundler right now because of this... pull requests mean that the project build is almost always red. :(
@indirect You mean the build that's showing first when someone's clicking on the badge and is linked to Travis CI?
The badge should normally reflect the branch status (assuming that you add a ?branch=master). The result for build images is normally fetched from a cache, and that is only updated when it's not a pull request build. There can be circumstances where this is not the case, a cold cache for instance, but normally it should reflect the right branch.
If it doesn't, that's something to investigate on our end.
It would be my expectation that Travis would ask Github for the name of the default branch. You can set this from the settings panel for the repository if you own it.
Then I would only expect to see commits on this branch to be shown on the "current" tab in Travis and I would expect the build status image to also default to this branch.
You would still be able to see the status of individual branches on the branch summary tab and pull requests on the pull requests tab.
Forgive me if this is what was already discussed but it wasn't obvious to me.