Publish Discovery and Evidence problem identifiers and the Registry Record context and profile - #2
Merged
Merged
Conversation
Advance the pinned Registry Stack commit to 9200b8403415a988e0dc1a 06c73df2e018af8db9, the newest ancestor of registry-stack main whose identifier catalog already carries complete registry-discovery and registry-evidence problem entries while predating the unrelated "profile" identifier kind introduced later in registry-stack history (not yet supported by this import pipeline). public/problems/ previously served only registry-relay identifiers even though the catalog also defines Discovery and Evidence problem types, so every documented Evidence or Discovery problem URI resolved to nothing. No generator changes were needed: scripts/build.mjs already renders problem pages generically per product, so re-importing the newer catalog and rebuilding is enough to publish registry-discovery/ (4 identifiers) and registry-evidence/ (10 identifiers) alongside the existing registry-relay/ identifiers. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
scripts/check.mjs already proves src/catalogs/problems.json is the exact set of problem entries in the vendored upstream catalog, and that public/ is byte-for-byte what scripts/build.mjs produces from the catalogs, so the guarantee already existed but only as the composition of two indirect proofs. Add scripts/check-problem-routes.mjs, which reads src/upstream/catalog.v1.json directly and asserts, for every kind: "problem" entry, that both its HTML and JSON route exist under public/ and describe the same code and HTTP statuses. It needs no live network access and no other check to have already run first. Wire it into npm test so CI runs it on every pull request and on the deploy workflow's pre-deploy build check. The vendored catalog it reads is refreshed with `npm run import:catalog -- <path> --source-revision <full-commit>`, documented alongside the new check in the README. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
The existing smoke-live.yml and smoke:live only check a small representative sample of identifiers, not every problem URI the catalog defines. Add scripts/smoke-problem-routes.mjs, which reads every active kind: "problem" entry from the same vendored src/upstream/catalog.v1.json scripts/check-problem-routes.mjs uses, fetches each one's canonical URI, and fails if any response is not HTTP 200. Wire it as a step in deploy-cloudflare-workers.yml right after the Cloudflare deploy step, so a deployment that leaves a documented problem URI unreachable fails loudly instead of surfacing later in the weekly representative smoke. IDENTIFIER_BASE_URL overrides the target host the same way it does for smoke-live.mjs, so this can run locally against a built public/ for verification before it ever runs against the live host. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Registry Stack publishes a Registry Record v1 JSON-LD context and a Registry Record v1 response profile. The importer refused the profile kind outright, and the build gave a context whose URI carries no file extension the same path for its artifact and its page, so neither kind could reach the site. Both kinds now import into their own source catalog, and one artifact writer serves every identifier that publishes bytes: the artifact at the canonical URI, the page beside it, and the immutable copy under the digest path. Each published path names its own content type, so a Markdown profile and a JSON-LD context are no longer served as JSON. The route check derives those three routes from the vendored catalog and fails when one is missing. Pages for artifact identifiers no longer default their product to Registry Relay, which linked Relay documentation from identifiers Relay does not own. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Advance the pinned Registry Stack commit to 48e4b1cfd92d26eec42784ac2a626b787de3f396, the current main of that repository, and re-import. The previous pin was chosen to predate the "profile" identifier kind because the import pipeline refused it; the pipeline now carries both artifact-backed kinds the BReg documentation already links, so the pin no longer has to avoid them. The catalog grows from 51 to 58 active identifiers: the JSON-LD context "contexts/registry-record/v1" and the profile document "profiles/registry-record/v1" appear for the first time, four schemas join (three BReg authoring and runtime schemas plus the registry-record schema), and one vocabulary joins. Every published record carries the new source reference, so each identifier's page names the upstream file it was generated from at the pinned commit. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Cloudflare Pages combines every rule matching a path and joins repeated header values, so an exact _headers rule for a schema path already covered by the /schemas/*.json wildcard produced doubled headers (e.g. Access-Control-Allow-Origin: *, *). Skip the exact rule when a static rule already sets the same content type and cache value for that path. Added scripts/build-headers.test.mjs, which builds the site and asserts no path resolves to a duplicated header name across matching _headers rules; it fails against the prior build.mjs and passes with the fix. Ran npm test (16/16 passing) and npm run build, then verified the regenerated public/_headers no longer emits an exact rule for schema paths covered by the wildcard (e.g. /schemas/breg/authoring/registry-module.v1alpha1.schema.json). Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d4c28ff6e9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The digest path of a published artifact serves the same bytes as its canonical URI, and the README requires both to carry the content type the kind defines. The immutable rule read the type from the file extension instead, so every schema copy under artifacts/sha256/ was served as application/json while its canonical URI served application/schema+json. Derive the immutable rule from the kind, drop the extension table, and pin the invariant with a test that compares both rules for every entry. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
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.
Publishes the Registry Discovery and Evidence problem identifiers (the site served only Relay's before), the Registry Record context and profile, and the context and profile identifier kinds, with a build-time check and a post-deployment smoke that every catalog problem URI resolves to a route. Six signed-off commits from the BReg and Evidence developer-experience review; registry-stack PR #850 carries the rest of that work.
Verification on the branch head:
npm testexits 0 (node --test: 16 tests, 0 failed;npm run check;npm run check:problem-routesreports 40 catalog problem identifiers resolving to built routes and 10 artifact identifiers resolving to an artifact, a page and an immutable copy).