@bompus/house-rules 0.14.0 → 0.14.2
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.
|
Binary file
|
|
Binary file
|
package/package.json
CHANGED
|
@@ -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
|
|
23
|
-
|
|
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"
|
|
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
|