Make Travis badge reflect master branch status

[jonathanperret]

Without a branch specifier, the Travis build status badge at the top of the README show the status of the latest build, which is not very useful and may give a wrong impression of brokenness.

[jvoigtlaender]

Makes sense, I'm ready to merge this, as it improves the current situation.

Something else to consider, though: Even with this new setup, one will see wrong status indications on the package site. Consider, for example, http://package.elm-lang.org/packages/elm-lang/core/3.0.0. It currenty indicates build failure. After your pull request is merged, it will indicate build success. But then as some stuff gets merged into the master branch here, said package page may again indicate build failure. While all the while, nothing has changed regarding the 3.0.0 release of core, and certainly it's not failing to build if one actually installs it locally.

So, is there a way maybe to let the badges on the package pages refer to the relevant release, rather than to the master branch?

[jvoigtlaender]

Makes sense, I'm ready to merge this, as it improves the current situation.

Something else to consider, though: Even with this new setup, one will see wrong status indications on the package site. Consider, for example, http://package.elm-lang.org/packages/elm-lang/core/3.0.0. It currenty indicates build failure. After your pull request is merged, it will indicate build success. But then as some stuff gets merged into the master branch here, said package page may again indicate build failure. While all the while, nothing has changed regarding the 3.0.0 release of core, and certainly it's not failing to build if one actually installs it locally.

So, is there a way maybe to let the badges on the package pages refer to the relevant release, rather than to the master branch?

[jvoigtlaender]

Also, maybe you can provide the same service (pull requests to make sure Travis badges refer to the correct thing) for other repositories under https://github.com/elm-lang?

[jvoigtlaender]

Also, maybe you can provide the same service (pull requests to make sure Travis badges refer to the correct thing) for other repositories under https://github.com/elm-lang?

[jonathanperret]

I'll gladly make similar PRs for the other repositories.

Regarding the badges on http://package.elm-lang.org/packages/elm-lang/core/3.0.0, I'll look into it. Though the badges seem out of place to me there: the fact that the package was released and published should be enough to know that it builds, shouldn't it? I'm thinking it would make more sense to remove the badges altogether on http://package.elm-lang.org, though this may require some kind of filtering on the README ?

Ideally, the badge would "know" on which page it is being rendered, and infer the current fork/branch from that. Unfortunately, this has already been requested and rejected by Travis, see travis-ci/travis-ci#1892. In any case, GitHub now hides every useful header from badge requests: https://github.com/blog/1766-proxying-user-images so there's little hope on having this work.

[jonathanperret]

I'll gladly make similar PRs for the other repositories.

Regarding the badges on http://package.elm-lang.org/packages/elm-lang/core/3.0.0, I'll look into it. Though the badges seem out of place to me there: the fact that the package was released and published should be enough to know that it builds, shouldn't it? I'm thinking it would make more sense to remove the badges altogether on http://package.elm-lang.org, though this may require some kind of filtering on the README ?

Ideally, the badge would "know" on which page it is being rendered, and infer the current fork/branch from that. Unfortunately, this has already been requested and rejected by Travis, see travis-ci/travis-ci#1892. In any case, GitHub now hides every useful header from badge requests: https://github.com/blog/1766-proxying-user-images so there's little hope on having this work.

[jvoigtlaender]

Thanks for investigating!

I agree that having the badges show up on the package site does not make very much sense, and even more so under the circumstances you have found out, that it is impossible to make them reflect the status of their relevant branch/tag.

On the other hand, removing the badges from the package site would indeed require some ad-hoc mangling of the README files. So I guess if the GitHub pages should have badges, we simply have to live with badges showing up on the package site as well.

It's still best in my opinion then to at least make sure the badges always reflect the status of the master branch, not some arbitrary different one. For that reason, I was simply going to merge your pull request. But now I'm actually wondering whether @evancz uses the badge deliberately as indicator of the status of the last commited-to branch, maybe better fitting into his development flow somehow? So I'll hold off a bit to see whether he comments on that.

[jvoigtlaender]

Thanks for investigating!

I agree that having the badges show up on the package site does not make very much sense, and even more so under the circumstances you have found out, that it is impossible to make them reflect the status of their relevant branch/tag.

On the other hand, removing the badges from the package site would indeed require some ad-hoc mangling of the README files. So I guess if the GitHub pages should have badges, we simply have to live with badges showing up on the package site as well.

It's still best in my opinion then to at least make sure the badges always reflect the status of the master branch, not some arbitrary different one. For that reason, I was simply going to merge your pull request. But now I'm actually wondering whether @evancz uses the badge deliberately as indicator of the status of the last commited-to branch, maybe better fitting into his development flow somehow? So I'll hold off a bit to see whether he comments on that.

[jonathanperret]

Thanks! I'll get on the other repos ASAP (probably later this week).

[jonathanperret]

Thanks! I'll get on the other repos ASAP (probably later this week).