feat(init): --vendor-schemas pins built-in schemas on-disk against upgrades (#431)#537
Open
avrabe wants to merge 1 commit into
Open
feat(init): --vendor-schemas pins built-in schemas on-disk against upgrades (#431)#537avrabe wants to merge 1 commit into
avrabe wants to merge 1 commit into
Conversation
…grades (REQ-220, #431) A project that lists only built-in schema names validates against whatever schema definitions are compiled into the installed rivet binary (the loader prefers on-disk, else the embedded copy). So every release that tightens a built-in schema silently changes validation for embedded-schema consumers — the same `rivet validate` that passed now flags unchanged artifacts. `rivet init --vendor-schemas` writes the resolved schema set (the names in `schemas:` plus auto-discovered bridges) from the binary's embedded copies into the project's `schemas/<name>.yaml`. Because the loader prefers on-disk, the vendored set is committed to the project's git and immune to release-to-release rule drift. Vendoring never overwrites an existing schema file. Confirmed: `rivet init --preset aspice --vendor-schemas` writes common.yaml + aspice.yaml, and `rivet validate` then reports them `(on-disk)` and PASSes; a locally-edited vendored schema survives a re-vendor. New `init_vendor_schemas_pins_schemas_on_disk` test; `cargo test -p rivet-cli --test cli_commands` 132 pass; clippy --all-targets + fmt clean; rivet validate PASS. Out of scope (separate slice): a rivet.yaml expected-version pin with a validate-time drift diagnostic; `rivet schema vendor` for existing projects. Implements: REQ-220 Refs: REQ-010 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
📐 Rivet artifact delta
Graphgraph LR
REQ_220["REQ-220"]:::added
classDef added fill:#d4edda,stroke:#28a745,color:#155724
classDef removed fill:#f8d7da,stroke:#dc3545,color:#721c24
classDef modified fill:#fff3cd,stroke:#ffc107,color:#856404
classDef overflow fill:#e2e3e5,stroke:#6c757d,color:#495057,stroke-dasharray: 3 3
Added
Posted by |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark 'Rivet Criterion Benchmarks'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.
| Benchmark suite | Current: cc303eb | Previous: 18db3e9 | Ratio |
|---|---|---|---|
traceability_matrix/1000 |
55095 ns/iter (± 210) |
43785 ns/iter (± 554) |
1.26 |
This comment was automatically generated by workflow using github-action-benchmark.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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.
What
A project that lists only built-in schema names in
rivet.yaml(no localschemas/) validates against whatever schema definitions are compiled into the installed rivet binary. So every release that tightens or adds a rule to a built-in schema silently changes validation for embedded-schema consumers — the samerivet validatethat passed now flags unchanged artifacts (#431).The version is already surfaced (REQ-176/177, #483) and CI warns on unbumped schema changes (REQ-206), but nothing let a project pin the schema set it validates against. This adds the one-step pin.
How
rivet init --vendor-schemaswrites the resolved schema set — the names inschemas:plus auto-discovered bridges — from the binary's embedded copies intoschemas/<name>.yaml. The loader already prefers on-disk over embedded, so the vendored set is committed to the project's git and immune to release-to-release drift. Vendoring never overwrites an existing schema file (a locally-edited schema is kept).Tests
init_vendor_schemas_pins_schemas_on_disk: vendors common+aspice, asserts the files exist, thatvalidatereports them(on-disk), and that a locally-edited vendored schema survives a re-vendor (idempotency guard).cargo test -p rivet-cli --test cli_commands132 pass; clippy--all-targets -D warnings+ fmt clean.Scope
This is the cheapest high-value slice of #431 (the issue's "mitigation that already works today", now one command). Out of scope (separate slices): a
rivet.yaml-recorded expected-version pin with a validate-time drift diagnostic, and arivet schema vendorcommand for already-initialized projects.Refs #431. Implements REQ-220.
🤖 Generated with Claude Code