I maintain an open source project and noticed that the CircleCI badge has changed from being a simple indicator, to also notifying people of CircleCI 1.0 being sunsetted.
Frankly, I’m not happy about this. This indicator seems to imply to users that there is something wrong with the project, even though the project has always been using CircleCI v2.
I do not want my users to have to see this for the next 2.5 months. It is information that is entirely irrelevant to the usage of the project.
Edit: As pointed out in the below comments, the wording of the indicator is also problematic since it is not clear that it’s CircleCI, and not the project, which is sunsetting its 1.0 branch.
I would like a way to clear this indicator from projects that have been verified as using CircleCI v2.
Perhaps this could take the form of an extra parameter on the badge URL:
Using that endpoint would give you the simple build indicator, and not include additional notifications about CircleCI’s 1.0 sunsetting.
Alternatively, CircleCI could change the badge returned based on the version used in the latest build(s). For projects using 2.0, return the badge without the sunsetting indicator.
This solution keeps it DRY, as project maintainers wouldn’t have to keep the badge URL in sync with the actual config file.
Philosophically, I would like to question whether it is even appropriate to have additional indicators there.
As a developer, I use the badge as a simple indicator of build status.
By adding the badge to my build, I’m asking users’ browsers to go and fetch an image from third-party servers. This means that I have to trust that third-party not to abuse their position and serve my users anything other than what they promised.
For example, a third party could become malicious and serve spam or malware using that image.
By adding the CircleCI badge, I trust CircleCI to serve my users the build status indicator, as per the “contract” of CircleCI’s docs: https://circleci.com/docs/2.0/status-badges/.
I understand that in this case, the information is useful and letting people know is important. It’s a clever solution to a tricky notification problem.
But in some sense, adding the indicator was a violation of trust. While CircleCI are the good guys and this notification was deemed beneficial, what happens in a hypothetical future where someone uses this as a precedent to inject (deemed beneficial) ads or other garbage?
I’d like to see CircleCI bind/restrict itself a bit more by publicly stating what sort of information could be added to future badges. An update to the status badges docs could suffice for this.
I think your philosophical point is most interesting, but is it not defeated by your trusting CircleCI not to show adverts? If you thought this was something CircleCI would do, or might do, then by definition you would not trust them, and thus you would not use their badge. That you did use their badge means that you don’t believe they would do anything that would represent a clear violation of trust.
My objection to your line of argument of course relies on the premise that the 1.0 message is not a violation of trust, which would be my position. I’d be inclined to agree with the assertion that it is perhaps not the best place for the indicator.
I’m trusting CircleCI not to abuse their position as a badge provider, by sticking to the (implicit) contract of supplying a simple build indicator.
I trust CircleCI, but I was surprised to find that the contract is looser than I expected from reading the docs.
This indicator was a (very mild) breach of my trust/expectations/contract. I still trust CircleCI, I’d just like to see better documentation of what they are (and are not) going to do with this “power”.
One thing you could do, if you would like to have more control over badges, is to use the API to determine the current build status - I imagine it supports that - and then serve badges from your own web server. That would give you ultimate control over badge types, and would reduce your users’ exposure to native or third-party badges.
@halfer: I agree. “breach of contract” is the wrong wording. I mean contract in the sense of expectations, not any sort of legal sense. Perhaps just “principle of least astonishment”, but slightly stronger since this is an area where I am accepting some risk by trusting CircleCI.
There are lots of workarounds (like trusting some other third party badge provider, or hosting a badge server myself), but the point is that I shouldn’t have to, since I trust CircleCI and they said that they would handle this.
Back in the practical, non-philosophical world, I might also remove the CircleCI badge until this blows over.
@bjornstar: Thanks for the reminder. That is what actually caused me to look into this at all. My project just went 2.0 a few weeks ago, so I was afraid that one of my co-maintainers has unilaterally decided to deprecate the 1.0 branch.
Thanks again for the feedback. We agree that this is not the right way to communicate this information. Please forgive the disruption to your workflow.
The update is rolling out now, so status badges will behave as they used to very soon.
