-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update badges in README #10341
Update badges in README #10341
Conversation
|
<img src="https://img.shields.io/github/discussions/badges/shields" /></a> | ||
<a href="https://github.com/badges/shields/actions/workflows/daily-tests.yml"> | ||
<img src="https://img.shields.io/github/actions/workflow/status/badges/shields/daily-tests.yml?label=daily%20tests" | ||
alt="Daily Tests Status"></a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this is the only one i'd push back on, as i'm still not a big fan of framing these as daily tests (and yes I know that nomenclature is already part of our vocabulary elsewhere)
setting aside that these have been executed on a different, greater than daily frequency, i think there's some value in reusing the "service test" verbiage that's utilized elsewhere so that contributors may perhaps more easily realize there's a connection when they see tests failing locally or in their PR
I don't feel terribly strongly about this though, especially if you and Chris prefer the daily test framing. just my .02 that we should be moving away from that framing instead of emphasizing it more 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't remember whether this was the case with the old "daily tests", but the new workflow in daily-tests.yml
runs more than just the service tests, it runs the core, entrypoint, package, and integration tests as well. If feels odd to me to narrow down the badge's label to a subset of what it's actually keeping track of. Maybe something like full test suite
would better represent what's being built underneath the hood?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah i think full test suite
would be a more accurate label
The more I thought about this recurring execution of tests today the more I realized I was stumbling into a can of worms that I don't think should be addressed here so I'll go ahead and 👍 and open a new issue to pose some thoughts/questions for discussion
Small opinionated pass on the badges at the top of our README: