Comment commands address the adopter's own App - #131
Merged
Conversation
App names are globally unique, so every installation has a different bot login. A constant handle could never be right in more than one repository: ours matched nothing in anyone else's, and because our App is public it rendered there as a mention of an account they never installed. /simplycubed avoided that but gave up the thing that makes a handle worth having. GitHub offers accounts with repository access in the autocomplete, so a real mention completes after someone types @A, without them knowing the bot's name. A prefix that is not an account cannot, and typing / opens GitHub's own menu, which then matches nothing. appName in .github/simplycubed.yml is the source of truth. The parser, the help text, and the wrong-surface replies all render from it, so the agent never tells anyone to mention a different account. The workflow trigger stays a literal, written by init from the same value. A workflow decides whether to start before any code runs, so matching loosely there would spin up a runner every time someone mentions a colleague: token, checkout, Go, CLI, sandbox, roughly thirty seconds, to then do nothing. That means the handle lives in two files and the App can only push one of them. preflight fails when they disagree, because the alternative is silent: comments stop working with no error anywhere.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
Codecov flagged 10 uncovered lines across main.go and command.go. Every one was a branch the change added and nothing exercised. resolveAppName decides what handle init writes, so each way it can be reached is now pinned: the flag, an existing config, the flag overriding a config, and neither. That last one matters most, because the error has to explain that the name is the adopter's rather than just demand a flag. appNameFor parses --repo-dir out of flags it does not own; both spellings are covered, since reading the wrong repository's config would silently answer as the wrong bot. Addressed and Parse with no configured App: a repository that has not said which App it installed has no handle to answer to. commandCmd surfacing a config error rather than parsing nothing, which would look like a comment the agent chose to ignore.
Merged
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
1 participant
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.
Replaces
/simplycubed <verb>with@<your-app> <verb>, per the research on #112.Why the prefix was wrong
/simplycubedfixed the multi-tenant bug but gave up the thing that makes a handle worth having. GitHub offers accounts with repository access in the autocomplete, so a real mention completes after someone types@a— they never need to know the bot's name. A prefix that is not an account cannot do that, and typing/opens GitHub's own menu, which is a fixed set of five built-ins and matches nothing.Atlantis reaches the same conclusion for the same shape of problem:
--executable-name, configurable "when running multiple Atlantis servers against a single repository."The design
appName:in.github/simplycubed.ymlis the source of truth. The parser, help text, unknown-command reply, and wrong-surface replies all render from it, so the agent never tells anyone to mention a different account. It acceptsacme-code,@acme-code, oracme-code[bot]— all three are how people write the same App.The workflow trigger stays a literal, written by
initfrom that same value. This is the part worth understanding: a workflow decides whether to start before any code runs. Matching loosely there would spin up a runner every time someone mentions a colleague — token, checkout, Go, CLI, sandbox, ~30s — to then do nothing.The cost, and how it is handled
The handle lives in two files and the App can push only one of them. So
preflightfails when they disagree, naming both and saying to re-runinit --workflow. Without that the failure is silent in the worst way: comments just stop working, with no error anywhere.init --app-nameis now required, with an error that explains why rather than just demanding a flag. Re-runninginitwithout it keeps whatever the config already says, so upgrading does not silently change the handle a team already types.Documentation
docs/setup.mdgains a section on why the handle is per-repository, which file owns it, and what to do on rename. The README shows a worked example withacme-code. Troubleshooting and STATUS follow.Tests
Handle normalisation; one repo's bot not answering to another's; empty
appNameparsing nothing; drift caught with both names in the message; no caller workflow being a valid local setup.This is a v0.3.0: it changes the config schema, makes an
initflag required, and changes the command surface.