release: v0.1.0 - #16
Draft
corpora-ui-automation[bot] wants to merge 8 commits into
Draft
Conversation
Lands the read-only half of section activation (#9). Schema, slug format and slug/repo uniqueness now live in one place, .github/scripts/sections.py, so the PR validator, the reconciler and the activation workflow cannot drift apart on what "valid" means. section-request.yml validates PRs touching sections/** and posts a single status comment that is rewritten in place. Drafts are validated too — an author should see schema errors while still drafting — but only the comment waits for ready-for-review so draft iterations don't spam the thread. Activation state is deliberately not checked here: a PR that merely files a request has no submodule yet, and demanding one would make every new request red. reconcile-sections.yml gains the navigation check. Its submodule check could pass while a section was still invisible: a submodule with no docs.json nav entries ships content nobody can navigate to. It stays read-only. The nav check walks the navigation tree rather than grepping the file, so it sees nested groups and tabs. Page paths include docs_path — a submodule clones a whole repository, so a source repo's docs/ lands at content/<slug>/docs/, not content/<slug>/. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Lands the write half of section activation (#9): steps 1 and 3 of "Activating a section" now run on a push to main that sets status: active. The result is always a pull request, never a push to main. The submodule pin and the mechanical nav rewrite are exactly the kind of change a human should read before it reaches the deploy branch. merge_nav.py splices each section in as one top-level group named after its label rather than flattening the source's groups in. Mintlify's navigation takes one top-level shape (tabs or groups, not both), and source repos commonly use names as generic as "Contributing" or "API" — one group per section preserves the source hierarchy and cannot collide with this repo's own groups. Re-running replaces the previous block for a slug instead of appending, so activation is idempotent. Step 2, connecting the Mintlify GitHub App, is dashboard-only with no API. It appears as an unticked checklist item at the top of the PR body, so merging an activation never implies the App is connected. Verified end to end against exegia/corpora-auth in a throwaway clone: the submodule pins, all 14 rewritten page paths resolve to real files, the reconciler goes green, and a second merge is a no-op. Manual runs default to a dry run, so the write path can be exercised without activating anything. Also corrects the docs' path example: page paths include docs_path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two failure modes found by re-testing the paths the first rehearsal didn't reach. The activation branch could not be updated. An activation PR that is opened but not yet merged leaves main without the submodule and nav, so the slug stays listed and the next sections/** push re-enters the loop for it. The push then failed: actions/checkout fetches a single ref, so there is no remote-tracking ref for the bot branch and --force-with-lease rejects with "stale info" — aborting the step under `set -e` before `gh pr edit` could run. Reproduced against a scratch remote; plain --force fixes it, and a lease buys nothing on a branch that is bot-owned and rebuilt from origin/main every run. validate_sections.py returned before writing --output when sections/ was absent. Git does not track empty directories, so archiving the last section deletes sections/ outright — a PR that still matches paths: sections/** and would then have died on `cat report.md` instead of reporting a verdict. Fixed in the script so both callers benefit. Also validated the merged docs.json against Mintlify's published schema: the three-level group nesting a tabs-structured source produces is accepted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The `guard` and `check` jobs have failed on every PR this repo has ever opened. `.github/` was copied wholesale from corpora-py, which carries a root `makefile`; that file did not come with it, so `make pr-guard` and `make ci` both died on "no such file or directory" — including on the three PRs that were merged past the red anyway. Ports the release-pipeline targets from corpora-py's makefile, adapted to a repo that publishes a docs site rather than a wheel: * VERSION replaces pyproject.toml as the manifest `pr-guard` cross-checks a release branch against and `tag-release` turns into the tag. Seeded at 0.1.0 to match the release/v0.1.0 branch already on origin. * `ci` validates docs.json and the sections registry instead of running ruff/mypy/pytest. Both checks are offline by construction: a `mint broken-links` would make the required status on every PR depend on a registry and a remote build. * No `pack`, and no `package` job — there is no artifact to build. The `check` job could not have gone green on the Makefile alone: it also ran `./.github/actions/setup`, which provisions uv against a uv.lock and a .python-version that this repo does not have. Both it and release.yml now set up Python the way the section workflows already do. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Everything removed here was copied from exegia/corpora-py and describes a
Python package this repo does not contain. None of it fires on a pull
request, which is why it survived the previous commit — but publish.yml
triggers on `push: tags: v*`, and `make tag-release` pushes exactly those,
so the first real release would have raised a red PyPI job on a repo with
no wheel to publish.
* publish.yml — PyPI trusted publishing for the corpora-py wheel.
* vercel.yml — manual deploy of corpora_py.app on Vercel's Python runtime.
This repo has no vercel.json and no .vercelignore; the site is built by
the Mintlify GitHub App, which is the deployment check on every PR.
* .github/actions/{build-dist,publish-pypi} — used only by publish.yml.
* .github/actions/setup — provisions uv against a uv.lock and a
.python-version that do not exist here. Nothing referenced it once the
`check` job stopped.
Also removes `package` from the main ruleset's required status checks. The
job it names was deleted with the wheel, and a required check that no
workflow produces would have left main unmergeable the moment
`make rulesets-apply` ran — the rulesets are not applied on GitHub today,
so this was latent rather than live.
The header comments in release.yml described the tag as feeding publish.yml
and a build-sidecar.yml that was never copied; they now describe what the
tag actually does.
Finally, .github/scripts/__pycache__ was tracked and re-churned on every
local run of the section scripts. Untracked and ignored.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fix: add the Makefile the PR workflow shells out to
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.
Release v0.1.0.
Changes
Refreshed automatically whenever a PR lands on
release/v0.1.0.