Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Badge Request: GitHub Check ignore pending builds #10221

Open
oliviertassinari opened this issue Jun 2, 2024 · 2 comments
Open

Badge Request: GitHub Check ignore pending builds #10221

oliviertassinari opened this issue Jun 2, 2024 · 2 comments
Labels
service-badge Accepted and actionable changes, features, and bugs

Comments

@oliviertassinari
Copy link

oliviertassinari commented Jun 2, 2024

馃搵 Description

I have migrated to https://shields.io/badges/git-hub-branch-status, but compared to the CircleCI badge, it shows the latest build status: SCR-20240602-qbse

while the CircleCI badge shows the latest non-pending build status. CircleCI seems the expected behavior. The use case is to be able to, with a glance, see if there is something to be worried about (broken CI branch).

It would be great if we could fix this.

@oliviertassinari oliviertassinari added the service-badge Accepted and actionable changes, features, and bugs label Jun 2, 2024
@PyvesB
Copy link
Member

PyvesB commented Jun 8, 2024

Hello @oliviertassinari 馃憢馃徎

Our GitHub branch status badge directly forwards the status returned by the GitHub API (see code) . I believe that this is the same status as the one shown in the GitHub UI (green check, red cross, orange dot). In addition to changing a historical behaviour which users seem happy with (this badge was implemented all the way back in #5973), I feel that introducing an inconsistency and having the badge show something different than the GitHub UI would be misleading and confusing.

@oliviertassinari
Copy link
Author

oliviertassinari commented Jun 8, 2024

I feel that introducing an inconsistency and having the badge show something different than the GitHub UI would be misleading and confusing.

@PyvesB I agree, these are fundamentally two different concepts.

The core of this issue is to request the introduction of another concept that I would expect to match the most common use case for this badge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
service-badge Accepted and actionable changes, features, and bugs
Projects
None yet
Development

No branches or pull requests

2 participants