hive-forge: ci-rerun --pr refuses instead of lying about a fix it can't achieve
A workflow_dispatch run writes no commit status, so ci-rerun --pr could never clear the red (pull_request) check it claimed to be re-running for - it dispatched a fresh run and printed a success message regardless, even though the check stays red no matter how that run turns out. --pr now refuses up front, before dispatching, naming the mechanism and the working alternative (re-run from the web UI). --run and --branch are unchanged: --run's own PR-pseudo-ref resolution and --branch's direct dispatch are both untouched. Fixes the exit-code/honesty defect from #4613; the workflow_dispatch vs. pull_request event-type question (whether to close+reopen the PR to fire a real pull_request event) is a separate, parked decision.
This commit is contained in:
parent
afdfce67ec
commit
92100ac1f8
2 changed files with 52 additions and 19 deletions
|
|
@ -103,7 +103,7 @@ hive-forge attach-comment 18042 /path/to/file # upload a file attachment to a c
|
|||
hive-forge attachment-get <uuid> # download an attachment; prints resolved path to stdout
|
||||
hive-forge artifact-get pr1ma-paper-pdf --run 51 # download a CI run's Actions artifact zip (run number from the run-page URL)
|
||||
hive-forge ci-log --run 51 # print a CI run's job step logs (run number from the run-page URL); --job i / --step i to narrow
|
||||
hive-forge ci-rerun --pr 42 # re-run CI without an empty commit (dispatches a fresh run; --run n / --branch name also work)
|
||||
hive-forge ci-rerun --branch foo # re-run CI without an empty commit (dispatches a fresh run; --run n also works; --pr refuses, see below)
|
||||
hive-forge subscription --watch # subscribe to repo notifications
|
||||
hive-forge subscription --unwatch # unsubscribe
|
||||
hive-forge subscription --list # list every repo you watch (audit the notification firehose)
|
||||
|
|
@ -293,12 +293,14 @@ to discover valid label names before triaging or to audit the label set.
|
|||
are CSRF-gated web routes a token POST 404s), so this dispatches a
|
||||
**fresh** run of the workflow via the workflow-dispatch API
|
||||
(`POST …/actions/workflows/<workflow>/dispatches {"ref":"<branch>"}`).
|
||||
Resolve the branch with exactly one of: `--pr <n>` (the PR's head
|
||||
branch), `--run <n>` (the same run number `ci-log` / `artifact-get`
|
||||
take — resolves the branch + workflow from that run), or `--branch
|
||||
<name>` (directly). `--workflow <file>` picks the workflow file for
|
||||
`--pr` / `--branch` (default `ci.yml`). Dispatch re-runs the whole
|
||||
workflow — there is no single-job variant.
|
||||
Resolve the branch with `--run <n>` (the same run number `ci-log` /
|
||||
`artifact-get` take — resolves the branch + workflow from that run) or
|
||||
`--branch <name>` (directly). `--pr <n>` refuses instead of dispatching:
|
||||
a workflow-dispatch run writes no commit status, so it can't clear a
|
||||
red `(pull_request)` check on that PR's sha — re-run from the web UI
|
||||
instead. `--workflow <file>` picks the workflow file for `--branch`
|
||||
(default `ci.yml`). Dispatch re-runs the whole workflow — there is no
|
||||
single-job variant.
|
||||
- `issue dependency <n> add <dep...>` / `pr dependency <n> add <dep...>`
|
||||
set "blocked by" links via Forgejo's dependency feature — the
|
||||
operator's preferred way to track blocking relationships over labels
|
||||
|
|
|
|||
Loading…
Reference in a new issue