Appveyor and Travis badge about better-enums HOT 9 CLOSED

I'm still thinking about this. I am considering disabling CI for master instead, since it will be redundant – everything will already have been tested before it gets merged. That would leave no good branch to use for a status image, unless I commit to having some kind of "staging" branch. If I use the latest build over the whole project, it might scare people away instead, since those can fail on any pull request.

There is also the matter of not making the README uglier :)

EDIT: To be more clear, I will be doing all merges in temporary staging branches that will get tested, then fast forward master to them on success. The same goes for pull requests that don't require special merging work. I am not sure if it's worthwhile to have a permanent staging branch only for the sake of having badges, but maybe it is.

from better-enums.

Currently master seems to be the latest stable branch. If the badge is limited to that branch, the users can see that this project has
a) tests
b) passing tests
just by looking at your README. These status images are not for you. You already tested the code and know that it works. But your users don't.

from better-enums.

I already understand that it's not for me, and that there is value in using something people immediately recognize.

Nonetheless, the badges communicate not exactly the right information about the project. The information I want to efficiently communicate is that master is always stable. The information the badges do communicate is that master is sometimes stable, but might not be, and that there are intervals when this information is pending because the build has not finished. In fact, there are never any such intervals. So, as you can see, the badges don't do what I really want.

I am even considering things such as using static images (with some ALT text to justify the deception for those who discover it). But I am also quite likely to just use the badges normally because it's simple, even though sloppy. I simply want to look for better options first. It's not an emergency and I am not being ignorant or stubborn.

I am aware of the ability to limit the badges to master. As I explained before, having builds for master is redundant because it wastes time building. It's also imprecise, because the build can be pending, when in fact a build of the exact same commit has already completed. I am trying to avoid these drawbacks, if it is possible in a reasonable way. Yes, they are minor, but, sorry for repeating, it's not such an emergency that I can't spend a few days thinking about it in my downtime. It's worth something to me if I can communicate the reliability of master as easily as a badge communicates the status of the latest build. If I can't, then I fall back to the regular badges.

I would appreciate any useful information you have. Please don't repeatedly tell me what I and everyone else who uses GitHub already knows.

from better-enums.

If you are looking for static images, shields.io might do what you want.

AFAIK if a build is pending/cancelled/in progress, travis/appveyor will display the last build status instead.

from better-enums.

Thanks, that looks cool :)

I don't know for sure if Travis/AppVeyor would display a pending status, but AppVeyor docs do mention configurable pendingText. Maybe they only show that if there is no previous completed build for a branch/project, but it still spooks me, at least at first glance.

from better-enums.

I just checked and travis does indeed wait for the build to complete before updating the badge. Appveyor displays a "pending" status image instead.

from better-enums.

Right, thanks. So, this behavior is acceptable, but not optimal.

It's a valid issue, just not immediately clear how to best resolve it. There is, after all, some value in even "redundant" master builds, since I might make a mistake when fast-forwarding, or doing something else.

from better-enums.

FYI

from better-enums.

Looks good!

from better-enums.