fix(actions): make the run id for run-watch/run-get obvious from the runs listing #466

New issue

Open

opened 2026-08-31 21:02:54 +00:00 by hexajon · 1 comment

hexajon commented

2026-08-31 21:02:54 +00:00

Owner

When a merge is gated on CI, I watch the run to see it pass. Going from actions runs to run-watch/run-get is not obvious, so I wasted time digging the id out of raw JSON instead of reading it off the listing.

What I saw

actions runs prints a run like this:

#182  [running] ci.yml

run-watch/run-get take a run_id, and their help says "the API id (not the web UI run number)". The listing shows #182 with a #, which reads as a web UI run number, so I did not trust it. In fact 182 IS the API id, and run-watch 182 works. The real web UI number is different: the run's html_url ends in /runs/28, and index_in_repo is 28. So:

the listing shows the API id (182), styled like a web number (#182)
the help warns against passing "the web UI run number"
the actual web UI number (28) is never shown

The one number the listing gives me is the right one, but everything about how it is presented says it is the wrong one.

Why the fallback hurts

Reading the id field from actions runs raw_json=true is the obvious plan B. At limit=1 it returns about 180 KB, because every run carries a full nested repository object, and it returns the whole page rather than one run. event_payload is already stripped, so that is not the cause. Getting the id back out then needs jq or a script.

Suggested fixes (any subset)

In the runs and run-get output, label the value plainly as the id to pass. For example id 182, or a run-watch 182 hint, instead of #182. Or show both the web number and the id.
Let run-watch/run-get also accept the web UI run number (index_in_repo), since that is what the URL and the web UI show.
Make runs raw_json lean: honor limit, and drop or summarize the per-run repository object, so the id is extractable without a script.

Related: #438 (finish should wait on a CI-gated merge instead of failing) is what sent me to watch the run by hand in the first place.

When a merge is gated on CI, I watch the run to see it pass. Going from `actions runs` to `run-watch`/`run-get` is not obvious, so I wasted time digging the id out of raw JSON instead of reading it off the listing. ## What I saw `actions runs` prints a run like this: ``` #182 [running] ci.yml ``` `run-watch`/`run-get` take a `run_id`, and their help says "the API id (not the web UI run number)". The listing shows `#182` with a `#`, which reads as a web UI run number, so I did not trust it. In fact `182` IS the API id, and `run-watch 182` works. The real web UI number is different: the run's `html_url` ends in `/runs/28`, and `index_in_repo` is 28. So: - the listing shows the API id (182), styled like a web number (`#182`) - the help warns against passing "the web UI run number" - the actual web UI number (28) is never shown The one number the listing gives me is the right one, but everything about how it is presented says it is the wrong one. ## Why the fallback hurts Reading the `id` field from `actions runs raw_json=true` is the obvious plan B. At `limit=1` it returns about 180 KB, because every run carries a full nested `repository` object, and it returns the whole page rather than one run. `event_payload` is already stripped, so that is not the cause. Getting the id back out then needs jq or a script. ## Suggested fixes (any subset) - In the `runs` and `run-get` output, label the value plainly as the id to pass. For example `id 182`, or a `run-watch 182` hint, instead of `#182`. Or show both the web number and the id. - Let `run-watch`/`run-get` also accept the web UI run number (`index_in_repo`), since that is what the URL and the web UI show. - Make `runs raw_json` lean: honor `limit`, and drop or summarize the per-run `repository` object, so the id is extractable without a script. Related: #438 (finish should wait on a CI-gated merge instead of failing) is what sent me to watch the run by hand in the first place.

hexajon commented

2026-09-15 21:43:54 +00:00

Author

Owner

It happened again on 2026-09-15. The listing showed #263, and I read it as the run in the web UI, but that run is web number 210. Live data for the fix:

Forgejo 15.0.6 names the web number index_in_repo (API id 263 is web run 210).
Gitea 1.27.3 names it run_number.

So "show both numbers" needs to read a different field on each forge. The field mapping is covered in the new actions-runs field issue.

It happened again on 2026-09-15. The listing showed `#263`, and I read it as the run in the web UI, but that run is web number 210. Live data for the fix: - Forgejo 15.0.6 names the web number `index_in_repo` (API id 263 is web run 210). - Gitea 1.27.3 names it `run_number`. So "show both numbers" needs to read a different field on each forge. The field mapping is covered in the new actions-runs field issue.

hexajon referenced this issue

2026-09-15 21:44:20 +00:00

actions runs: madtea reads only Gitea's run fields, so Forgejo runs show no branch or start time #504

hexajon referenced this issue

2026-09-15 21:44:25 +00:00

actions runs raw_json: Forgejo ignores limit, so raw_json returns every run (1.4 MB) #505

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#466

No description provided.

Rows
Columns