Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add generic URL option for status png to make forking readmes on github display correct repo #779
The current status icon is great for many things, but has its own issues within github.
Say I have a project and the readme has a reference to the status icon, http://travis-ci.org/DavidJFelix/example.png . John Doe forks my project and does a bunch of work, but his readme points to my status icon, regardless of whether or not he has travis-ci setup. This can mean inaccurate information is displayed. This means that perhaps John will need to ignore certain parts when pushing/pulling and make use of filter-branch more frequently.
Say for another example that I'm a travis-ci zealot and I'm telling a friend how helpful travis-ci can be for projects! I see his project sitting out on github and I think "I know! I'll just patch travis-ci support for him, and all he has to do is turn it on in the admin panel". If I send him a pull request, I have to either set up a hard address for him to pull (this can be further complicated if my friend is organization, and the person who turns on travis could be any admin member of the group).
My proposal is to expand the current controller that handles status images to accept a static route (perhaps travis-ci.org/status_img.png) and check the referer URL. If the URL doesn't exist or can't be linked to a travis user/repo - it reports unknown status. If it parses as a github repository and can be found as a linked repository, display the icon! That way forks can immediately reflect build status.
This could also be expanded to be more reliable. The current solution proposed could be unreliable if the client doesn't report referer url or if an outside site strips the readme for internal documents. In these cases, perhaps the github hooks api could be used to make travis aware of forks that exist/the network graph. This is only really necessary if the referer url proves to be too reliable.
I tried to get help implementing this myself, but I just can't be bothered to learn rails 3 just to implement a 3-10 line pull request - I know it's this simple, but I haven't used rails in years so I can't figure out how. I'll donate $35USD to travis in the name of any person who helps me implement this - regardless of whether the pull request is accepted or not.
Displaying "unknown" status if url does not match certain URL, will be petty limiting - people can add status images not only in the README on github (and even if only there, sometimes README is displayed also in other locations, like docs). That's why I'm -1 on this specific solution.
What we could do is to display image for a main repository by default, display image for fork if url matches one of the github's fork urls and allow to whitelist other locations for forks. However, I'm not sure how realistic is merging such thing at the moment - please note that after implementing this code, we need to support and scale it for thousands of repos. The other problem is that putting such whitelist in
That said, I certainly would like to further discuss, please just not be so fast on implementation before we can discuss the specifics.
The idea is not to replace the current /[user]/[repo].png for most applications, but to add an alternative URL designed for the volatility of a github README's location. If, from the above examples John Doe forks my repository, technically speaking, the build status of his repository is not known until he sets up travis for the repo. You know that mine builds and happily advertise that on his page, but when he makes a thousand broken changes the icon will still say "passing" when in fact nobody has any idea. In addition, if somebody pulls down a static version and puts it in their repository and you view their readme there... the build status is not known - the build they took down could have been ages ago, but the icon will happily display "passing" because now the software passes. The point is that travis-ci integrates with github and that github urls are very reliable when it comes to finding repositories on travis's side - if it's not github and the user on github doesn't have a project by the name that's asking then you can't possibly know the build status - because it's not in travis.
I'm not looking for anything people have to change in the .travis.yaml or configure. All they would have to do is change it in their readme, and if it turned out that too many people block referer URLs from being sent in HTTP headers and their image displays unknown, they could switch back. As long as the current system stays in-tact it literally could be one of the lowest risk changes -- but, that's beside the point. While I'd like to see the functionality, all I really want is for somebody to tell me how (in travis's code) I can do what I'm thinking. If this implementation isn't right, the Pull Request can get rejected. It's not that I care about my code making it into travis, I'm just utterly frusterated with learning the entirety of Rails 3 just so I can know how exactly to write a route for this and how/where to use Rails' built in HTTP-referer. So, in my mind I'd be happy and satisfied with just information on how to fix this myself, which boils down to the following questions:
So let me explain again. I know the fix in my mind is literally less than a dozen LOC changes... I can see it above 1 route, 1 small controller function that uses 2-3 builtin or pre-existing functions. Whether it is valid or not can be left to discussion on a pull request, or here for all I care, but if somebody helps me write those dozen LOC and feed my insatiable hunger to know the answer (without having to be a Rails 3 expert - I don't need that) I'll donate to the project. A pull request isn't rushing implementation. Anyone else can counter it with their own suggested changes.
@DavidJFelix I could tell you where to implement it, but we would like to retire rails app soon anyway and then status images would be probably moved elsewhere, which I think it's not decided yet. If you implement it now, we will either have to port it later or wait for someone else to do it. I'm not saying that we don't want this feature at all and I do realize that we can reject the pull request if we don't like it, but this is definitely not high priority thing at the moment.
referenced this issue
Jan 25, 2014
I'm trying to figure out how referrer might be sensitive and can't put my finger on it. Github URLs are pretty generic -- I guess they might have information about private repos, but that would only be name data, which I'm fairly sure is exposed through user activity pages as well. I wonder if they could be persuaded to accept a patch to add referrer.
While camo itself obfuscates the referrer one possible solution is for
On Friday, February 5, 2016, David J. Felix email@example.com