Merge pull request 'fix(ci): trigger on edited so un-drafting actually lifts the draft skip' (#18) from fix/ci-edited-trigger into main

.gitea/workflows/ci.yaml

@@ -5,27 +5,27 @@ on:
     branches: [main]
   pull_request:
     branches: [main]
-    # Spelled out only to keep `ready_for_review` in the list — naming any type
+    # Spelled out only to keep `edited` in the list — naming any type replaces
-    # replaces the whole default set, so the other three have to be restated.
+    # the whole default set, so the other three have to be restated.
-    # It is inert on this instance (draft state here is the `WIP:` title
-    # prefix, so un-drafting is a title edit and raises no
-    # `ready_for_review` action) and costs nothing.
     #
-    # The consequence, which is the part that bites: the `if:` guard below is
+    # `edited`, not `ready_for_review`: draft here is the `WIP:` title prefix,
-    # evaluated when a run is CREATED, and un-drafting creates no run. A PR
+    # so un-drafting is a title edit and no ready-for-review action is ever
-    # opened as a draft keeps its skip decision until something else produces
+    # raised. That edit is what creates the run which lifts the `if:` skip
-    # one. Push an empty commit after un-WIP'ing.
+    # below (decided once, when a run is CREATED). Do not swap it back and do
-    types: [opened, synchronize, reopened, ready_for_review]
+    # not drop this to the bare default — either restores the bug. The accepted
+    # cost and the evidence are in README's Development section.
+    types: [opened, synchronize, reopened, edited]
 
 # gitdan-ci runs four repos' CI on two capacity slots, and the compiler-backed
 # suites below are multi-minute. A superseded run costs a slot in front of
 # somebody's build, so drop it.
 #
 # `push` groups on `github.sha` rather than `github.ref`: a constant per-branch
-# group is what let this Gitea (1.26.0) cancel two of daniel/gitdan's merge
+# group is what let this Gitea cancel two of daniel/gitdan's merge runs
-# runs outright while `cancel-in-progress` was gated away from `push` entirely
+# outright while `cancel-in-progress` was gated away from `push` entirely —
-# — see the long note in that repo's ci.yaml for the evidence. Giving every
+# see the long note in that repo's ci.yaml. Observed on 1.26.0; the instance
-# commit its own group leaves that behaviour nothing to act on.
+# is 1.27.2 now and whether it persists is unverified, which is why every
+# commit gets its own group instead of trusting the flag.
 concurrency:
   group: ${{ github.workflow }}-${{ github.event_name == 'pull_request' && github.ref || github.sha }}
   cancel-in-progress: true

README.md

@@ -605,10 +605,43 @@ cannot measure) and references no credentials; the scratch workspaces the
 compiler-backed suites build use path dependencies only, so nothing reaches
 crates.io. It runs the full suite rather than `--fast`,
 because the two compiler-backed suites are the ones that check this scheme
-against real Cargo instead of against a fixture. Draft (`WIP:`-titled) PRs
+against real Cargo instead of against a fixture.
-skip it, and un-drafting does **not** un-skip them — the guard is evaluated
+
-when a run is created and un-drafting creates none, so push an empty commit
+**Draft (`WIP:`-titled) PRs skip it; un-drafting un-skips them, through
-after un-WIP'ing.
+`edited`** — no empty commit needed. The skip is decided when a run is
+*created*, so lifting it needs an event that creates one, and un-drafting on
+this Gitea is a title edit: `edited` is in the workflow's `pull_request` types
+for exactly that reason. `ready_for_review` held that slot first and never
+fired — this Gitea has no draft column and no ready-for-review event at all,
+draft being computed from the title prefix — so a PR opened as `WIP:` carried
+its skip decision all the way to merge unless some later push happened to
+create a run. Do not swap the type back and do not drop the `types:` list to
+its bare default; either restores the bug.
+
+**Accepted cost: a body edit on an already-non-draft PR now triggers a real
+run.** Gitea populates no `changes` field for a title-or-body edit, unlike
+GitHub, so the workflow cannot tell the edit that un-drafts a PR from an
+ordinary body PATCH — a closing-reference fix-up, say. The price is around
+**90 seconds** of a runner shared across four repos on two capacity slots: the
+last twelve non-skipped runs of this job, `started_at` to `completed_at` off
+the Actions API, are 83 s median over 77–106 s. `timeout-minutes: 20` is a
+ceiling for a hung suite, not a duration. It is also bounded: the workflow's
+`concurrency:` block groups `pull_request` runs on `github.ref` with
+`cancel-in-progress: true`, so a burst of edits collapses to one run rather
+than N. A still-draft PR pays nothing extra — the `if:` guard skips those
+exactly as before.
+
+The evidence for `edited` comes from `daniel/emowheel`, which hit the identical
+bug, shipped the identical wrong fix, and corrected it in commit `08da820` (see
+`daniel/emowheel#71`): Gitea 1.27.2's `HookIssueAction` enum has no
+`ready_for_review` entry and no notifier emits one, while
+`issue.IsWorkInProgress` derives draft from the title. Live since: emowheel PR
+#141 was un-drafted at 19:01:13 on 2026-08-31 and run 2801 was created two
+seconds later on the **same** head SHA as the two runs skipped before it — a
+run created by the title edit alone, with no push, that executed and passed.
+`daniel/gitdan` ported the same one-word change. That it behaves the same way
+*here* has not been demonstrated in this repo; the next `WIP:` PR opened
+against `main` is the test.
 
 This repo is consumed by three other repos' CI at `@v1`, a moving tag, so a
 change here reaches all of them at once. That is what the gate is for.