Repository navigation
feat: surface "install the GitHub App" hint after successful upload - #7
Conversation
Customers who follow the in-app setup page verbatim — add the action, generate an API token, push — see green CI but an empty dashboard when the BuildPulse GitHub App isn't installed on the repository. The process-test-results Lambda logs a warning to CloudWatch and moves on; from the customer's perspective there is no diagnostic. Add a core.notice right after the upload succeeds that calls out the app-install requirement as the first thing to check if data doesn't appear within ~10 minutes. This is a CI-side breadcrumb, not a runtime check (no extra API hop), so it adds zero latency to the happy path while pointing the customer at the right resolution when they hit the failure case. Rebuild dist/. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
buildpulse-agent
Bot
added
the
agent-review-pending
loera140
added
agent-reviewed
loera140
left a comment
loera140
left a comment
There was a problem hiding this comment.
Agent code review
Walkthrough
Adds a core.notice() call after a successful BuildPulse upload to tell users where to look for results and that the most common cause of missing data is the BuildPulse GitHub App not being installed on the repo. The change is purely additive observability — no control flow, auth, or output behavior is altered. dist/index.js is regenerated to match src/index.js, as expected for an ncc-bundled action.
Findings
- No issues found.
Verdict
APPROVE. Small, additive, low-risk UX/observability change. core.notice with a title option is the standard @actions/core API (≥1.6.0; this repo pins ^1.10.1). The compiled dist/index.js hunk is line-for-line consistent with the src/index.js hunk, so the bundle is in sync. No tests are deleted or weakened, no scope drift, no secret/PII exposure, and the message is framed conservatively ("most common cause") rather than as a definitive backend claim.
Confidence
HIGH — read both changed files in full; diff is two identical hunks (source + compiled bundle) of a single additive core.notice call.
1 participant
Summary
After a successful upload, emit a `core.notice` that calls out the BuildPulse GitHub App install as the first thing to check if the dashboard stays empty.
Why
Onboarded a fresh repository tonight against the live setup page and discovered the silent-failure path: when the GitHub App isn't installed on the customer's repo, every upload reaches S3 but the processing Lambda drops it with `no repository document found for providerRepoId=X`. CI shows green. Dashboard stays empty. No customer-visible diagnostic.
This adds a CI-side breadcrumb pointing at the actual resolution. Zero extra API hops on the happy path. (`web-client` PR #85 fixes the in-app setup page in parallel.)
Test plan