Skip to content

docs: fix branch-protection accuracy; tighten cluster-safety test #50

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mrjasonroy merged 1 commit into from
Jun 25, 2026
Merged

docs: fix branch-protection accuracy; tighten cluster-safety test #50

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 14 additions & 6 deletions docs/auto-release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,18 +54,26 @@ CI is green — the tag and publish still fire automatically from your merge.

`main` requires the status checks `lint-and-typecheck`, `unit-tests`, and
`test-summary`, and does **not** require an approving review — the checks are the
gate, and no bot can give itself an approval. Required conversation resolution
stays on (only matters when a human leaves review comments). Auto-merge and
delete-branch-on-merge are enabled at the repo level.
gate, and no bot can give itself an approval. **Required conversation resolution
is off**: an auto-reviewer (e.g. `gemini-code-assist`) leaves review threads on
every PR, and with conversation resolution required those unresolved threads
would block auto-merge — wedging the hands-off bump loop on every release. The
e2e status checks are the real gate. Auto-merge and delete-branch-on-merge are
enabled at the repo level.

To re-add a human approval gate later:
To re-add a human approval gate later (the `required_pull_request_reviews`
sub-fields are included because the GitHub API rejects a partial object):

```bash
gh api -X PUT repos/{owner}/{repo}/branches/main/protection --input - <<'JSON'
{ "required_status_checks": { "strict": false,
"contexts": ["lint-and-typecheck", "unit-tests", "test-summary"] },
"enforce_admins": false,
"required_pull_request_reviews": { "required_approving_review_count": 1 },
"restrictions": null, "required_conversation_resolution": true }
"required_pull_request_reviews": {
"dismiss_stale_reviews": false,
"require_code_owner_reviews": false,
"required_approving_review_count": 1
},
"restrictions": null, "required_conversation_resolution": false }
JSON
```
10 changes: 8 additions & 2 deletions packages/cache-handler/src/data-cache/redis.test.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -424,8 +424,14 @@ describe("RedisDataCacheHandler cluster safety", () => {
vi.setSystemTime(new Date(BASE_TIME.getTime() + 5000));
await handler.get("k2", []);

// Both deletion paths must have run (otherwise the assertion is vacuous)...
expect(commands.some((c) => c.method === "del")).toBe(true);
// Both deletion paths must have run (otherwise the assertion is vacuous),
// and each must delete exactly the one expected key — tag-driven del of k1,
// then TTL-driven del of k2.
const delCommands = commands.filter((c) => c.method === "del");
expect(delCommands).toEqual([
{ method: "del", keys: ["nextjs:data-cache:k1"] },
{ method: "del", keys: ["nextjs:data-cache:k2"] },
]);
// ...and every command issued must target exactly one key.
const multiKey = commands.filter((c) => c.keys.length !== 1);
expect(multiKey).toEqual([]);
Expand Down
Loading