fix(cli): make --canary-bot reachable on init - #247
Open
ignaciocanosa wants to merge 1 commit into
Open
Conversation
The closing checklist init prints tells the user to re-run it with --canary-bot=<your-app>[bot] to enable the weekly canary, but the flag was missing from validateLocalFlags's allowlist in cli.mjs (and from the value-taking list, and from the global help text). The documented command failed with "Unknown option: --canary-bot" before init() ever ran, so the canary stays on its default forever and the watchtower reports that as a healthy skip rather than a misconfiguration. Added init to the allowlist and value-taking list for the init command, and to the help text. Added two tests: one renders init with --canary-bot=my-app[bot] and asserts it lands in facility-crew.yml (and the default does not leak in), the other asserts a valueless --canary-bot still errors and that global help documents the flag. Reverted the fix locally and reran: both fail with exactly the reported error; reapplied it, both pass. Ran the full packages/cli suite: no new failures. 12 tests already fail on a clean checkout of main on this machine (chmod semantics, fixtures needing infra this environment doesn't have) — confirmed via the same suite on an unmodified checkout, unrelated to this change. Fixes theam#229
adrian-lorenzo
requested changes
Sep 1, 2026
adrian-lorenzo
left a comment
Member
There was a problem hiding this comment.
Thanks for the contribution!
Making this flag reachable also makes its value a new input to the generated crew workflow. It is currently accepted verbatim and interpolated into both the Actions if: expression and a Bash comparison. A value containing quotes can therefore produce executable shell syntax in facility-crew.yml.
Please validate it as a supported GitHub App bot login, or safely encode it for every output context, and add regression tests covering quotes, newlines, and other hostile values. Because this workflow runs agents with elevated permissions, the unsafe input case needs to be covered before merge.
With that fixed, this should be ready.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #229.
What was broken
init's closing checklist tells the user to re-run it with--canary-bot=<your-app>[bot]to enable the weekly canary, but the flag was missing fromvalidateLocalFlags's allowlist incli.mjs— the CLI rejected it withUnknown option: --canary-botbeforeinit()ever ran. The documented path to enable the canary was unreachable, and the watchtower reports the resulting default-skip as healthy rather than as a misconfiguration.Fix
Added
canary-botto theinitallowlist, to the value-taking flags list (it takes a value), and to the global help text.Verification
packages/cli/test/init.test.mjs: one runsinitwith--canary-bot=my-app[bot]and asserts it's rendered intofacility-crew.yml(and that the default doesn't leak in when overridden); the other asserts a valueless--canary-botstill errors correctly and that--canary-botis documented in global help.Unknown option: --canary-bot, nothing else. Reapplied — both pass.packages/clisuite (108 tests): no new failures. 12 tests already fail on a clean checkout ofmainon this machine (chmod-permission assertions, fixtures needing infra unavailable here) — confirmed against an unmodified checkout with the same command, unrelated to this change.