@bompus/house-rules 0.14.0 → 0.14.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@bompus/house-rules",
3
- "version": "0.14.0",
3
+ "version": "0.14.1",
4
4
  "description": "Composable working rules and skills for AI coding agents",
5
5
  "homepage": "https://github.com/bompus/house-rules#readme",
6
6
  "license": "MIT",
@@ -8,6 +8,38 @@ Give jobs finite timeouts. Cancel an older pull-request run only when a newer
8
8
  run for the same pull request covers the same required checks; preserve required
9
9
  default-branch and release evidence.
10
10
 
11
+ ### Cancel superseded pull-request runs
12
+
13
+ Key the `concurrency` group on the workflow and the pull request number, and
14
+ cancel only for pull-request events:
15
+
16
+ ```yaml
17
+ concurrency:
18
+ group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }}
19
+ cancel-in-progress: ${{ github.event_name == 'pull_request' }}
20
+ ```
21
+
22
+ - Concurrency groups are shared by every workflow in the repository, so keep a
23
+ value unique to the workflow in the key. `github.workflow` is the workflow's
24
+ name, so it is unique only while workflow names are; otherwise use a fixed
25
+ prefix. Without a unique value, one workflow's run can cancel another's.
26
+ - Keep the pull-request key stable across pushes: never a commit SHA or run ID
27
+ for a pull-request run, which differs on every push, so nothing is cancelled.
28
+ A workflow that runs only on pull requests can use `cancel-in-progress: true`.
29
+ A reusable workflow inherits the caller's `github.workflow`, so give caller and
30
+ callee different keys.
31
+ - Cancellation needs a newer run in the same group. When a path filter means a
32
+ push starts no run, the older run finishes. Add a cleanup workflow only when
33
+ run history shows older runs finishing after pushes that started no
34
+ replacement; it must not check out pull-request code.
35
+ - To skip checks on draft pull requests, add `github.event.pull_request.draft != true`
36
+ to each check job's `if`, including reusable-workflow callers and aggregate
37
+ jobs. A job guard stops a runner being allocated; a step guard does not. Add
38
+ `ready_for_review` and `converted_to_draft` to the `pull_request` types, so
39
+ checks start when review begins and a replacement run can cancel old work.
40
+ Use this only when the repository's policy says draft pull requests do not
41
+ need these checks.
42
+
11
43
  ### Choose the concurrency boundary
12
44
 
13
45
  Independent jobs can run on separate runners. A job's steps normally run in
@@ -19,8 +19,8 @@ the review body too: findings outside the diff arrive there, not as threads.
19
19
  Let an enabled automatic review start; do not comment to request one. When none
20
20
  starts, check the integration's status instead of tagging the bot again. A bot's
21
21
  config file in the repository does not show that it is enabled, and an existing
22
- check on the head must report completion before you merge (for CodeRabbit, a
23
- successful status whose description starts with "Review completed").
22
+ check on the head must report completion before you merge. A skipped or
23
+ cancelled review is not a completed one.
24
24
 
25
25
  During integration, never switch, reset or remove the session's own checkout: no
26
26
  `checkout` or `switch` to another ref, no `reset` or branch force-move, and no
@@ -19,7 +19,9 @@ the head contains `.coderabbit.yaml`. It also checks bot review bodies with
19
19
  outside-diff, nitpick or duplicate findings. A completed CodeRabbit CheckRun
20
20
  must conclude SUCCESS; failed, cancelled, skipped or missing conclusions block
21
21
  the gate. A CodeRabbit status also requires SUCCESS and a description starting
22
- with "Review completed". It does not check every CI result or authorize landing.
22
+ with "Review completed"; that is how the gate tests the general squash rule that an
23
+ existing review check must report completion. It does not check every CI result or
24
+ authorize landing.
23
25
 
24
26
  The check named exactly "cubic · AI code reviewer" on the head commit is held to the
25
27
  same rule: while it runs, the gate refuses, and a completed one must conclude