Repository navigation
Rediscover the App installation ID when the target repo changes - #176
Merged
Merged
Conversation
…hanges Repointing a configured deployment at a new repository wrote the new REVIEWER_REPO alongside the previous repo's REVIEWER_APP_INSTALLATION_ID: configure-inner.sh seeded the ID from reviewer.env whenever --installation-id was omitted, so the auto-discovery branch never ran. The daemon then minted tokens for the old installation and 404d on every call against the new repo, while the summary reported success. configure.sh could not repoint at all -- it never re-prompted for a REVIEWER_REPO that was already set. Both entry points now treat a changed repo as a repoint: the inherited installation ID is dropped so it gets rediscovered, an explicit --installation-id still wins, and the summary prints the resolved ID. Also gitignore config/*.bak*, so an operator backup of reviewer.env no longer leaves the checkout dirty and makes sync-worktree.sh skip the tick.
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.
Repointing a configured deployment at a new repository wrote the new
REVIEWER_REPOalongside the previous repo'sREVIEWER_APP_INSTALLATION_ID, so the daemon minted tokens for the old installation and 404d on every call against the new repo — while the summary reported success.configure-inner.shseeded the installation ID fromreviewer.envwhenever--installation-idwas omitted, so the auto-discovery branch never ran.configure.shcould not repoint at all: it never re-prompted for aREVIEWER_REPOthat was already set.Both entry points now treat a changed repo as a repoint — the inherited ID is dropped so it gets rediscovered, an explicit
--installation-idstill wins, and the summary prints the resolved ID (its absence is why this failed silently).Also gitignores
config/*.bak*: an operator backup ofreviewer.envleft the checkout dirty, which makessync-worktree.shrefuse to sync and skip the tick entirely.Verification
Run against the live VM and the real GitHub API, using an isolated env file:
--installation-idKnown gap
No fixture coverage: the suite is scoped to
scripts/reviewer/and mocks reviewer libs, so a setup-script test does not fit it without a new harness. Verified end-to-end by hand instead — stronger evidence than a mock, but no regression guard. Ascripts/tests/harness for setup scripts would be its own piece of work.