-
-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Fix job status aggregation logic #35000
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
Conversation
I think #34823 (comment) can resolve the problem. |
No.. The picture is what I just observed 🤦♂️ (before patch) I personally see no need to introduce another run status |
However, the aggregation logic differs between running/waiting and failure states in two key ways: To address this, I see two possible solutions: |
|
* giteaofficial/main: [skip ci] Updated translations via Crowdin Increase gap on latest commit (go-gitea#35104) Fix job status aggregation logic (go-gitea#35000) Fix some missed GitHeadRefName when renaming (go-gitea#35102) Fix error logs and improve some comments/messages (go-gitea#35105) Support Basic Authentication for archive downloads (go-gitea#35087) Run `uv run` with `--frozen` (go-gitea#35097) Improve package API log handling (go-gitea#35100) Rename pull request GetGitRefName to GetGitHeadRefName (go-gitea#35093) Fix review comment/dimiss comment x reference can be refereced back (go-gitea#35094) Fix submodule nil check (go-gitea#35096) Redirect to a presigned URL of HEAD for HEAD requests (go-gitea#35088)
For a run (assume 2 jobs) that has a failed job and a waiting job, the run status should be waiting, as the run is not done yet.
Related #34823