Repository navigation
docs(claude): don't suggest an existing runner label for a new host - #107
Conversation
Reviewer's guide (collapsed on small PRs)Reviewer's GuideUpdates the new-host documentation to use a non-copyable runner-label placeholder and explicitly warn that reusing an existing label can send deployments to the wrong host. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 1 issue
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="CLAUDE.md" line_range="295" />
<code_context>
Follow `docs/superpowers/runbooks/adding-a-new-host.md` (the generic step-by-step procedure). Highlights:
-- Pick a unique runner label (e.g. `piwine-office`)
+- Pick a runner label no other host uses (e.g. `<node>` for a new `docker-<node>` repo; reusing an existing label such as `piwine` routes deploys to that host's runner)
- Add the label to **both** `compose-workflow/.github/actionlint.yaml` and the caller repo's `.github/actionlint.yaml`
- Run host prep (deploy user, path ownership pattern, `safe.directory`, umask 002 in admin's rcs)
</code_context>
<issue_to_address>
**Shared label does not route deploys**
When a new caller repo reuses a label registered only to another repo, the deploy job's label match is limited to runners registered for its own repository, so it does not reach the existing host; without a runner registered to the new repo, the job stays queued.
Replace the warning with the repository-scoped behavior: a reused label cannot select another repo's runner, and the new repo needs its own registered runner.
</issue_to_address>Sourcery assessment
Approval pending. 1 finding to address first.
Blocking findings: CLAUDE.md:295
|
|
||
| Follow `docs/superpowers/runbooks/adding-a-new-host.md` (the generic step-by-step procedure). Highlights: | ||
| - Pick a unique runner label (e.g. `piwine-office`) | ||
| - Pick a runner label no other host uses (e.g. `<node>` for a new `docker-<node>` repo; reusing an existing label such as `piwine` routes deploys to that host's runner) |
There was a problem hiding this comment.
🟡 Medium · Shared label does not route deploys
When a new caller repo reuses a label registered only to another repo, the deploy job's label match is limited to runners registered for its own repository, so it does not reach the existing host; without a runner registered to the new repo, the job stays queued.
Replace the warning with the repository-scoped behavior: a reused label cannot select another repo's runner, and the new repo needs its own registered runner.
Prompt for AI agents
In `CLAUDE.md` at line 295:
**Shared label does not route deploys**
When a new caller repo reuses a label registered only to another repo, the deploy job's label match is limited to runners registered for its own repository, so it does not reach the existing host; without a runner registered to the new repo, the job stays queued.
Replace the warning with the repository-scoped behavior: a reused label cannot select another repo's runner, and the new repo needs its own registered runner.
Sourcery review of #106: the new-host example label was
piwine-office, which is already registered. Copying it would route a new host's deploys to the office Pi's runner. It's now a<node>placeholder with a note about why the label must be unique.Summary by Sourcery
Update host onboarding guidance to require unique runner labels for new self-hosted hosts.
Bug Fixes:
Documentation: