-
-
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
Remove commit status running and warning to align GitHub #25839
Remove commit status running and warning to align GitHub #25839
Conversation
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.
Please check also templates/repo/commit_status.tmpl
Co-authored-by: Jason Song <[email protected]>
Hmm… I'm conflicted about that decision. |
I don't think people care about whether a commit status is Yeah, for Gitea Actions, |
Co-authored-by: Jason Song <[email protected]>
From my experience GitHub UI definitely has
I guess it makes some sense to be API-compatible with GitHub, but internally I guess we would still need them for above two reasons. |
According to the github documentation:create-a-commit-status, creating a status only accepts |
You're right we have to distinguish:
So I'm fine with reducing the commit status to those GitHub-compatible values. |
Can we ensure that for our actions workflow runs, the statuses there are correctly mapped down to those 4 values? |
I'm sure, but we should be aware that it could lose some detail, you know, it's “mapping down”. |
Even if we don't reduce those two statuses, Gitea is also compatible with Github. Why these two statuses are unnecessary? |
So |
There might be some remaining unused conditionals in UI now for the icon, need to check. |
…#26036) Also added comments so the next time the dashboard repo list won't be forgotten Follows #25839 Signed-off-by: Yarden Shoham <[email protected]>
* giteaoffical/main: (22 commits) Serve pre-defined files in "public", add "security.txt", add CORS header for ".well-known" (go-gitea#25974) Use frontend fetch for branch dropdown component (go-gitea#25719) Remove commit status running and warning from the dashboard repo list (go-gitea#26036) Refactor to use urfave/cli/v2 (go-gitea#25959) Remove commit status running and warning to align GitHub (go-gitea#25839) Fix escape problems in the branch selector (go-gitea#25875) Update README.md to fix the broken link of Hugo (go-gitea#26008) Support copy protected branch from template repository (go-gitea#25889) Update JS dependencies (go-gitea#26025) Reduce margins on admin pages (go-gitea#26026) Actions Artifacts support uploading multiple files and directories (go-gitea#24874) [skip ci] Updated translations via Crowdin Remove redundant "RouteMethods" method (go-gitea#26024) Adding remaining enum for migration repo model type. (go-gitea#26021) RPM Registry: Show zypper commands for SUSE based distros as well (go-gitea#25981) Fix the route for pull-request's authors (go-gitea#26016) Remove nfnt/resize and oliamb/cutter (go-gitea#25999) Correctly refer to dev tags as nightly in the docker docs (go-gitea#26004) Fix env config parsing for "GITEA____APP_NAME" (go-gitea#26001) Add file status for API "Get a single commit from a repository" (go-gitea#16205) (go-gitea#25831) ...
Noticed this PR in the 1.21-rc0 changelog. I think commit status "warning" was useful for checks where you want to draw the attention of the developer, but not block the merge of the PR. e.g. sonar static code analysis has severities, and we want to block the merge for newly introduced [Blocker, Critical, Major] violations, and give a warning for [Minor] violations. And jenkinsci/gitea-plugin will also break because it uses warning to report unstable build (test failures): |
I guess these have to migrate to |
On second thought, |
I checked another data point, GitLab. Here is a table illustrating the commit statuses of each:
|
Personally I don't see any benefit from this change. Why do we need this to be compatible with GitHub in expense of breaking existing integrations? |
I guess I agree to restoring |
|
So, partial revert of this that edits the migration as well? Of course the damage to existing statuses is already done for anyone using prereleases. |
Do we actually want to revert this? If we do, it's better to do this sooner so the damage is minimal |
Yes, someone please raise a PR with the revert. We also need to disable this part of the migration. If no one raises the revert, I can probably do it in a few days. |
I think there is already an existing revert PR. |
#27504 for the partial revert. |
Partial revert of #25839. This commit status is used by a number of external integrations, so I think we should not remove it (See #25839 (comment)). This is a rare case where an existing migration needed to be alterted to avoid data loss. --------- Co-authored-by: delvh <[email protected]> Co-authored-by: Giteabot <[email protected]>
Partial revert of go-gitea#25839. This commit status is used by a number of external integrations, so I think we should not remove it (See go-gitea#25839 (comment)). This is a rare case where an existing migration needed to be alterted to avoid data loss. --------- Co-authored-by: delvh <[email protected]> Co-authored-by: Giteabot <[email protected]>
Backport #27504 by @silverwind Partial revert of #25839. This commit status is used by a number of external integrations, so I think we should not remove it (See #25839 (comment)). This is a rare case where an existing migration needed to be alterted to avoid data loss. Co-authored-by: silverwind <[email protected]> Co-authored-by: delvh <[email protected]>
Fix #25776. Close #25826.
In the discussion of #25776, @wolfogre's suggestion was to remove the commit status of
running
andwarning
to keep it consistent with github.references:
So the commit status of Gitea will be consistent with GitHub, only
pending
,success
,error
andfailure
, whilewarning
andrunning
are not supported anymore.