Repository navigation
Webhook: a repo's hook carries push events - #2796
Conversation
GitHub never sent a push to Lore: the repo hook subscribed to pull request, review, comment, issue and repository events, and pipeline.events holds no github.push in the week before 2026-10-17. So the stations' push handler for the Utopia commit mirror (and the protected-branch base-moved event the map has carried since) could never fire. push joins the required events, so the ensure step adds it to a hook that lacks it and the status reports such a hook as narrow_events.
|
Lore is reviewing this PR — b4da5665-c630-47ce-9eff-3db38be0d3e5. Submit a review that requests changes to have Lore push a fix for it. Comment |
Lore Spec ImpactLore API unreachable (HTTP 000000). This check could not run. |
There was a problem hiding this comment.
Lore review — Approved
Adds push to REQUIRED_EVENTS so classifyWebhook flags hooks missing push as narrow_events and ensureLoreWebhook subscribes repo hooks to branch pushes.
Must fix (0) · Consider (0) · Nits (1)
Reviewed by gemini-4-argon
Submit a review that requests changes to have Lore push a fix for it. Comment @lore review to re-run the review.
Posted by floor, visit 5086a0fb-5e00-41bd-8f60-57ef277e14f6.
There was a problem hiding this comment.
Lore review — Approved
Spec update accurately lists check_suite (completed) among the mapped X-GitHub-Event events.
Must fix (0) · Consider (0) · Nits (0)
Reviewed by gemini-4-argon
Submit a review that requests changes to have Lore push a fix for it. Comment @lore review to re-run the review.
Posted by floor, visit d9379a89-1ac7-4853-bcdd-86894545079d.
…5) (#2802) Utopia held each repo's default-branch commits, but a pull request or an issue appeared only as a number and a link, taken from a squash-merge's commit message, and releases and tags not at all. This PR mirrors GitHub's own record of every issue, pull request, tag and published release into the repo's knowledge base (`specs/utopia-graph-mirror` FR14 and FR15, ADR-052 amendment of 2026-10-17). **Issues and pull requests.** GitHub's issues listing returns pull requests too, with their merge time, so a single walk covers both. It reads oldest update first from a new cursor, `settings.utopia.tracker_since`, and pushes `pull:<n>` and `issue:<n>` items. Each item holds title, state (open, closed or merged), the login that opened it, labels, the open, close and merge times, and the description. A pull request's `Closes`/`Refs`/`Lore-Task:` lines link it to its issues and task, stated through a module the commit mirror now shares, so both mirrors say the same thing about the same entity. The walk takes up to 2,000 entries per run, moves the cursor past each one that lands, and stops at the first failure. **Tags and releases.** A `tag:<name>` item points to the commit the commit mirror names, and a `release:<tag>` item (title, author, publish time, notes) publishes its tag. That way a release reaches the pull requests behind it. A repo has few of these, so every push sends them all, with no cursor: an unchanged item answers unchanged, and a refused one is sent again next time. Drafts are skipped. **When it runs.** - A changed issue or pull request emits `github.tracker.changed`; a published or edited release, or a created tag, emits `github.release.changed`. Both come from the same delivery under its own dedupe key (`github:<id>:utopia`). - The stations answer by posting `POST /api/repos/{owner}/{repo}/utopia/tracker` or `/releases`. - The weekly backfill runs both after the commits. - A repo's hook now requires the `release` and `create` events. An existing hook gets them when the ensure step runs for that repo, as `push` did in #2796. - The commit, tracker and release walks share one loop and one per-repo queue (`cursor-walk.ts`). This branch is rebased onto #2801: commit items carry no file names, and the commit walk takes the newest 200. **Ontology version 5.** Version 5 adds `Release` and `Tag`, `points_to` and `publishes`, and the tracker attributes. Once it deploys, every base below 5 re-imports the ontology on its next push. If re.8 is not live by then, those bases store 5 with every relation typed as a state, so after the apply the reset is `5 → 4`, not `4 → 3`. Out of scope: reviews, review comments, conversation comments, and tombstoning deleted issues, releases or tags. Checks run locally: vitest across libs/shared, apps/lore-api and apps/stations; `tsc --noEmit` on every package that imports shared; `eslint .` with 0 errors; `prettier --check`. Generated with [Claude Code](https://claude.com/claude-code)
GitHub has never delivered a
pushto Lore. The repo webhook thatensureLoreWebhookkeeps subscribes to pull request, review, comment, issue and repository events, andpipeline.eventsholds nogithub.pushin the week before 2026-10-17 while every other event type arrived hundreds of times. So the stations' push handler from #2790, which walks a merged commit into Utopia, could never fire, and only the Sunday backfill would walk commits. The same applies to the branch-push eventgithub-map.tshas mapped for a protected branch's moving base.pushjoinsREQUIRED_EVENTS. The ensure step (on onboarding, andPOST /api/repos/{owner}/{repo}/webhook/ensure) then adds it to a hook that lacks it, and the status route reports such a hook asnarrow_events. The webhook spec's event list gainspushand no longer claimscheck_suitemaps to nothing, sincegithub-map.tsmapscheck_suite.completed.After deploy, each onboarded repo's hook is updated with one ensure call.
Related: #2790 (the push handler this feeds).
🤖 Generated with Claude Code