Update from code changes: remove remix review and in-client docs - #1641
Open
mintlify[bot] wants to merge 1 commit into
Open
mintlify[bot] wants to merge 1 commit into
mintlify[bot] wants to merge 1 commit into
Conversation
Contributor
Author
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
vendo-release-bot Bot
pushed a commit
that referenced
this pull request
Sep 1, 2026
…hes (#88) Releasing was a round trip. `changeset version` ran on the PUBLIC repo, so the version bump — bumped package.json versions, CHANGELOGs, the emptied .changeset/ — existed there and nowhere else, and an hourly poll (upstream-import's `schedule`) had to carry it back in through Copybara's CHANGE_REQUEST mode. Every release therefore cost two human-merged PRs and a reverse import computed against a baseline that mode can only ever find one release stale. This turns the loop into a line. THE NEW FLOW, END TO END 1. A PR merges to private main with a changeset in it. 2. That push runs .github/workflows/version-packages.yml, which runs `changeset version` on `changeset-release/main` and keeps ONE standing "chore: version packages" PR open against private main, with native auto-merge armed behind the eight private required checks. 3. That PR is fast-laned: every required check reports green in ~2 minutes without building or testing, because its diff cannot break anything the merges it is versioning did not already break. 4. Merging it releases. sync-public projects the bump to runvendo/vendo like any other change. 5. On public, tag-and-release.yml sees packages/vendo naming a version with no tag, pushes `v<version>` with the plain GITHUB_TOKEN, and dispatches release.yml, which publishes to npm over OIDC. 6. Coming the other way, upstream-import polls hourly for a public main commit this repo did not write and opens an import PR. Docs-only imports arm their own auto-merge; anything wider waits for a human. WHAT CHANGED .github/workflows/version-packages.yml NEW. changesets/action on private main, release-bot App token (persist-credentials: false — the action writes its own .netrc), a disarm-first/re-arm-last pairing around the 0.x ceiling guard. .github/workflows/monorepo.yml cone/test-shards/test-rest skip on the version PR; compile skips build+typecheck but keeps the two tree guards; projection-suite skips its two heavy steps (step-level, because it is required by name). .github/workflows/console.yml the five lanes gain the version-PR clause on the `if:` they had. .github/workflows/site.yml version-PR case ahead of the SCOPE .github/workflows/screen-checker.yml probe, which the version PR matches. .github/workflows/broker.yml comment only: they carry no .github/workflows/machine-proxy.yml packages/** scope, so they already skip green on the version PR. .github/workflows/upstream-import.yml the version-bump resolver deleted for good; `pr` is a required, digits-only dispatch input; a SLIM hourly `schedule:` replaces it, keyed on the GitOrigin-RevId trailer, and arms auto-merge on docs-site-only imports. .github/workflows/sync-public.yml comment only. oss/.../version-packages.yml -> tag-and-release.yml the changesets half and the auto-merge machinery deleted; the tag + dispatch half kept verbatim, incident comments and all. oss/.github/workflows/ci.yml comment only: `heavy` is dormant oss/.github/workflows/release.yml rather than removed. See RISKS. CLAUDE.md, CONTRIBUTING.md, the release flow as it now is, .changeset/README.md layered on top of #85's rewrites. The 0.x ceiling survives in both halves and still takes two deletions to lift: the private guard refuses to PROPOSE a version that left 0.x, the public one refuses to TAG one. Neither moves without Yousef's word. ROLLOUT a. DONE — the precondition that used to gate this branch is satisfied. It was: import public PR #1708 (the 0.62.0 bump) into private before merging, or (i) sync-public's un-imported-content guard refuses every projection and (ii) this branch's own merge push opens a DUPLICATE 0.62.0 version PR that auto-merges and wedges tagging forever, since v0.62.0 already exists. Import #84 landed it. Verified on origin/main: packages/vendo says 0.62.0, public says 0.62.0, and public main is now "chore(pipeline): delete the dead weight (#85)" carrying GitOrigin-RevId 445afeda3 — the sync is projecting again. Kept here as the record of why the order mattered, not as a step anyone still has to take. b. STILL TO DO, at merge time — delete public's `changeset-release/main` branch. It still exists (checked), and once the public workflow is gone it is an orphan nothing owns. Close any "chore: version packages" PR sitting on it first. The sync removes the old version-packages.yml from public by itself; the branch is the only manual sweep. c. Merge order: (b) lands -> this branch merges. The merge push runs the new private version-packages.yml, which will QUIETLY DO NOTHING: the only pending changeset (.changeset/light-lemons-decide.md) is an empty one, and at this pin the action logs "All changesets are empty; not creating PR" and returns (src/index.ts:154-156). The first real changeset after that opens the version PR and exercises the flow end to end. d. Manual dry run, any time: the workflow is push-only by design, so dry-run it locally instead — `pnpm install --frozen-lockfile && pnpm changeset:version`, read the diff, throw it away. Run twice while building this: once pre-rebase against a real changeset (0.61.2 -> 0.62.0 across both packages, both CHANGELOGs, both version constants, NO lockfile churn), and once post-rebase against the empty changeset now on main (consumed it, bumped nothing, constants already correct). Both are the right answer. e. Rollback = revert this commit. It restores the public version PR, the old hourly import and today's behaviour; oss/ci.yml's `heavy` detection was deliberately left in place so a revert needs nothing else. THE DOCS IMPORT LANE, AND WHY THE POLLER CAME BACK HALF-ALIVE Deleting the hourly poll removed the version round-trip, which was the point, and also removed the only thing draining Mintlify's docs edits inward. Those merge natively onto PUBLIC main, docs-site/** is PROJECTED, and sync-public's un-imported-content guard refuses to project while public holds content this repo has not absorbed. That guard now stands in front of releases, so an un-imported docs edit stops shipping — a chore nobody remembers had become a load-bearing part of the release pipeline. So the schedule is back, carrying none of the version logic: - It asks ONE question, the same one sync-public's guard keys on: does public main carry a GitOrigin-RevId trailer? Copybara writes one on every commit it pushes, so a HEAD without one is public's own. Depth-1 fetch, one `git log -1`, and an ordinary run exits there before installing git or a JDK. Run against real public main while writing this: HEAD is "chore: version packages (#1708)", trailer EMPTY — native, correctly detected. - It imports public main AS IT STANDS, not the native commit it spotted. The change is parented on private HEAD, so one commit carries everything public has that private does not — exactly the set the guard refuses to overwrite. A narrower import would leave part of it behind and the guard red. - CHANGE_REQUEST mode makes that ONE SQUASHED COMMIT, never a commit-by-commit replay: it writes the projected public tree as a single commit on a baseline and rebases it. Six merged mintlify PRs arrive as one import PR. - Docs-only imports arm their own auto-merge; anything wider is left open like a community import. The file list is read from the PR, paginated, so a wide import cannot slip through truncated at 100 files. Proven against real PRs rather than reasoned about: public #1641 (mintlify, 11 files) filters to nothing outside docs-site/ -> would arm; public #1708 (the version bump, 7 files) filters to all 7 -> would be left for a human. - Arming is scheduled-only. A dispatched import is a maintainer importing a contribution, and those stay human-reviewed even when they touch only docs. - The shared-branch lock is unchanged, and red runs are still the nag: a scheduled run that finds an import PR already open cannot push and fails loudly every hour until that PR is merged or closed. A docs import runs the FULL private suite, deliberately. docs-site/** is in turbo's globalDependencies, so it fans out to every package — and it should: the docs-rot tests readFile docs-site/*.mdx. Nobody is waiting on it. RUNBOOK, TWO CONSEQUENCES WORTH KNOWING BEFORE THEY BITE - THE PUBLISH PATH NOW RUNS THROUGH sync-public's un-imported-content guard. A release that stalls is diagnosed at a RED sync-public run, not at a red release job. Anything merged natively on public blocks that guard until it is imported inward. ELEVEN mintlify PRs are open and armed on public right now (#1474, #1475, #1571-#1573, #1636-#1641), and every one of them lands as a native commit. They stop being a release hazard once the schedule above is live: the version gap that used to sit alongside them is closed (private and public are both 0.62.0), so the import they trigger is docs-site-only and merges itself. Public main carries a sync trailer as of #85, so the probe says "nothing to import" until the first of them merges — which is the healthy steady state, confirmed by running the probe for real. - NPM PUBLISH NO LONGER WAITS ON PUBLIC ci/integration/conformance/audit. Those gated the public version PR; there is no public version PR any more, so the bump reaches main as a sync push and tag-and-release.yml acts on it. Accepted, and recorded rather than discovered later: the content already passed the private required checks before it was versioned, and release.yml still builds and typechecks before it publishes. RISKS AND AMBIGUITIES - The version PR's two SOURCE files (the CLI and core version constants) go untested on it. They cannot disagree with package.json — one script writes all three — and public has skipped the same tests on the same PR for months. - oss/ci.yml's `heavy` detection is kept, not deleted. Half-removing it (dropping the two `case` lines) would leave five dead `if:` gates behind; removing it whole is a six-site edit to public CI for no gain. It is inert while no version PR exists there and correct again on a rollback. It also keeps its `changeset-release/*` glob while the private files all use the exact branch name — deliberate: that file belongs to the public repo. - `branch:` is deliberately NOT passed to changesets/action. At this pin it names the PR's BASE branch and the head is derived as `changeset-release/<base>`, so the default already yields exactly the wanted pair; passing `changeset-release/main` would have produced `changeset-release/changeset-release/main`. - `persist-credentials: false` was verified against the pinned action source, not assumed: commitMode defaults to "git-cli" so the branch really is pushed by the git CLI, but src/index.ts writes $HOME/.netrc from the token before any push, unconditionally. Same App identity either way. - The disarm step reads `autoMergeRequest` before calling `--disable-auto` rather than wrapping it in `|| true`. Whether gh no-ops on an unarmed PR is a belief this repo has never tested (the 0.x guard's `|| true` hides it); asking first lets the disarm itself stay strict, which is the whole point of a step that exists to close a window. - CLEARED SINCE THE FIRST DRAFT: `allow_auto_merge` is now ENABLED on runvendo/vendo-cloud, and the App's Pull-requests: write on this repo is proven in production — PR #78 shows an author of `vendo-release-bot[bot]` and merged. Neither is a rollout step any more. - REBASED ONTO #85, which landed the pipeline deletions. Both sides kept where they overlapped: monorepo.yml carries #85's docs force-full pathspec and the removal of projection-verify AND this branch's version-PR fast-lane; oss/ci.yml carries #85's docs cone repair and the ai-dual removal AND this branch's comment updates, with `heavy` still in place. copybara-verify.sh was deleted by #85, so this branch's comment edit to it went with it and the one comment here that cited it now cites sync-public.yml's guard instead. The CLAUDE.md and CONTRIBUTING.md release wording sits ON TOP of #85's local-gate and browser-suite rewrites, not over them. GitOrigin-RevId: e7516a24cc6d5fae1933bcaffd68929b6b07f53d
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.
Summary
Removes documentation for the retired in-client native execution / remix review flow and cleans up remaining references, following the removal of those features (and
vendo eject) from the product.Changes
<Remixable review>→<Remixable>, drop theapps.review.reviewerhook)/apps/review-queue,/apps/:id/ship-diff,/apps/:id/reject-review, and/dev/inclient-approvalroutes from the HTTP routes referencereview.reviewerrow from handler options and thereview: truecapture row from sync docsContext
vendo eject; its CLI, uninstall, and troubleshooting doc updates shipped with that PR, so no further eject changes were needed