forked from heavy-duty/ceremony
935a813d75
`.github/workflows/labels.yml` dispatched the sweep with `gh workflow run`, the eighth runtime gh call site the 0.6.0 merge reintroduced and the only one !204 did not port. On this forge the runner carries neither gh nor a GitHub API, so the step refused and the entire event-driven reconcile path ended there — every transition waiting up to an hour for the scheduled sweep. The workflow-dispatch endpoint has the SAME shape on both forges: POST {api}/repos/{owner}/{repo}/actions/workflows/{file}/dispatches {"ref": "<branch>", "inputs": {...}} -> 204, empty body so the step no longer decides a forge at all. The CEREMONY_FORGE_CLIENT=gh declaration and both inline refusals are removed rather than ported, and test/no-runtime-gh.test.sh now asserts their ABSENCE — an opt-out with no gh behind it is a standing permission slip. The ref is supplied explicitly and taken from the repository, never from GITHUB_REF_NAME: on a pull_request_target run that is `<n>/merge`, which is not a branch. A non-204 still fails the job, keeping the misconfiguration alarm the trigger exists to be, and the diagnostic explains Forgejo's empty 500 rather than passing a bare status to a reader who will go looking for an outage that is not there. test/labels-dispatch.test.sh extracts the shipped step and executes it against a recording stub, asserting the method, endpoint, ref and inputs actually sent. Dropping the inputs or ignoring a non-204 both red the suite. Refs #205 |
||
|---|---|---|
| .. | ||
| DISCUSSION_TEMPLATE | ||
| ISSUE_TEMPLATE | ||
| scripts | ||
| workflows | ||
| labeler.yml | ||
| labels.conf | ||
| pull_request_template.md | ||