-
-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Description
Description
Here's what's happening:
Let's say I have only 1 runner registered. If I push a commit to a repo that triggers 2 workflows, one grabs the runner and shows as “running” in the UI, the other shows as Waiting, cool. But here comes the problem.
The Problem
When I poll the /repos/{owner}/{repo}/actions/tasks
endpoint, I get back the response JSON with fields workflow_runs
and total_count
, but only the running one is in workflow_runs
array meaning there is no mention of the workflow that is showing as waiting in the web UI. The one that’s showing as waiting in the web UI isn’t in the list at all until a runner frees up and it actually starts, then it shows up as "status": "running"
.
Also, this doesn't only happen on new workflow when you commit (or whatever way your trigger a workflow) but all workflows, like if you re-run a workflow, it doesn't show in the response until it starts actually running
when a runner becomes available.
The tasks endpoint is supposed to schedule and track workflows atleast that's how I see it, to enqueue workflows. It should list all workflows that need to run (with a waiting
status), not just the ones currently executing.
How I’d expect it to work
- I GET
/actions/tasks
- Response includes every triggered workflow, each with:
"status": "waiting"
if no runner is available"status": "running"
once a runner picks it up"status": "success"/"cancelled"/"failure"
as usual afterward
How to reproduce
- Register ** any number of runners less than the number of workflows triggered** on a repo.
- Push a commit that triggers those n Actions workflows.
- Immediately GET
/actions/tasks
endpoint. - Observe that only those workflow in the JSON which are actually running and no mention of those which are showing as Waiting in the web UI.
Possible fix
When scheduling tasks, add every workflow to the queue with a waiting
status. Then flip to running
as soon as a runner picks it up. Failure and cancellation already work fine.
Why it matters
I’ve got one central CI repo dispatching builds to a bunch of child repos. I rely on /actions/tasks
to track each child workflow’s status. Right now, if a child is waiting for a runner, it never shows up in the API call and my orchestration pipeline totally breaks.
Let me know if something isn't clear.
Gitea Version
1.24.2
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
Ubuntu 24.04.2 LTS
How are you running Gitea?
Running Gitea rootless in docker using the official gitea image gitea/gitea:1.24.2-rootless
.
Database
SQLite