ci: auto-move new GitHub issues to swamp.club lab

[stack72]

Summary

Adds the same Issue Auto Responder action that systeminit/swamp ships in systeminit/swamp#1134. Every new issue filed against systeminit/swamp-extensions is mirrored to the swamp.club lab via POST /api/v1/lab/issues/ensure, the GitHub issue receives an auto-responder comment linking to the new lab home, and the GitHub issue is closed.

The workflow is byte-identical to swamp's because it derives the repo from context.repo and posts that to swamp.club's ensure endpoint — the lab will see githubRepoFullName: "systeminit/swamp-extensions" automatically. No code changes were required to copy it across.

Verified compatibility

• swamp.club's /ensure validates githubRepoFullName against ^[\w.-]+\/[\w.-]+$ (swamp-club/routes/api/v1/lab/issues/ensure.ts:86). systeminit/swamp-extensions matches.
• No per-repo allowlist anywhere in swamp-club — any owner/repo shape is accepted.
• The endpoint requires an admin-role caller (user.role !== "admin" → 403). systeminit/swamp-club#370 only opened up /api/v1/lab/issues (the public submission endpoint), not /ensure. So this PR needs an admin-role API key in the secret.

Why the close is gated

Same safety property as the swamp action: a GitHub issue must never be closed unless its lab counterpart exists. The flow short-circuits on every error:

1. POST to /api/v1/lab/issues/ensure. If non-2xx → core.setFailed + return (issue stays open).
2. Validate data.issue.number is a safe positive integer. If not → core.setFailed + return (issue stays open).
3. Post the auto-responder comment with the lab URL.
4. Only then close the GitHub issue.

Required before merge

• Add the SWAMP_CLUB_API_KEY repo secret with an admin-role swamp.club API key. Reusing the same swampadmin key that's configured on systeminit/swamp is the cleanest path.

Test plan

After merge:

• Smoke test: file a throwaway issue against systeminit/swamp-extensions. Expect:
  • The issue closes within seconds of being filed.
  • A comment appears with the auto-responder text and a https://swamp.club/lab/<n> link.
  • The lab issue exists at that URL with the original body plus the Automoved by swampadmin from GitHub issue #<n> footer.
• Failure-mode test: temporarily revoke the SWAMP_CLUB_API_KEY secret value (or point at an unreachable host) and file a throwaway issue. Expect:
  • The action run fails with a core.setFailed message.
  • The GitHub issue stays open.
  • No auto-responder comment is posted.
  • Restore the secret afterwards.

Related

• feat: auto-move new GitHub issues to swamp.club lab swamp#1134 — the swamp-side counterpart this mirrors.
• systeminit/swamp-club#369 — the swamp-club PR that introduced the sequential numeric lab issue ids that the validator in this action is mirroring.
• systeminit/swamp-club#370 — the swamp-club PR that opened up /api/v1/lab/issues (not used here — the auto-mover uses /ensure for idempotency and structured GitHub linkage).

🤖 Generated with Claude Code

[github-actions]

Code Review

Blocking Issues

None.

Suggestions

1. Hardcoded type: "feature" — all issues (including bug reports) will be created with type: "feature" in the lab. If the lab's API supports other types (e.g. "bug"), you might want to map GitHub labels or leave this as a follow-up.

2. Error response body logged to CI — core.setFailed(swamp.club ensure failed: ${ensureRes.status} ${text}) logs the raw response text to the CI log. If the server ever reflects authentication details in error bodies, those would appear in CI output. Low risk (CI logs are restricted), but worth keeping in mind.

3. No label: "closed-moved" on close — The swamp counterpart (systeminit/swamp#1134) may add a label when closing. Not required, but could help distinguish auto-closed issues from organically closed ones.

The sequential gating (POST → validate lab issue number → comment → close) is correctly implemented and matches the stated safety property. Permissions are scoped minimally (issues: write, contents: read). Secret is injected via env var, not hardcoded. Timeout and error handling look solid.

[github-actions]

CI Security Review

Critical / High

None.

Medium

1. .github/workflows/auto-response.yml:9 — contents: read permission is unnecessary. The workflow never checks out code or reads repo contents; it only interacts with issues and an external API. Removing contents: read would tighten the permission set. Not exploitable — the default GITHUB_TOKEN already has this permission in public repos.

Low

None.

Verdict

PASS — Clean workflow. Issue data is handled safely via JavaScript objects and JSON.stringify() (no shell interpolation). The labIssueNumber from the external API response is validated as a safe positive integer before use in URL construction. Secrets are passed via environment variables, not string interpolation. The actions/github-script action is GitHub-owned and acceptable with tag pins.