ci: refuse a schema change an older lerd cannot read - #87
Merged
Merged
Conversation
Definitions here reach every install within a day, whatever version of lerd is running, and there is no version gate on the way in. An old binary will read a definition written long after it shipped, so the schema may only grow, and the moment to catch a change that breaks that is the pull request rather than the day after it ships. The guard flattens every document to a set of paths and types, compares the branch against what is published, and fails on the two changes an older binary cannot survive: a key that disappeared, and a key whose type moved under it. A value no published definition has used before is reported as a warning instead, because widening the accepted values of a key breaks an old switch exactly as retyping does, but only the author knows whether the binaries in the field already understand it. Both the types and the closed value sets come from the published tree itself, so nothing here needs updating as the schema grows.
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.
Definitions here reach every install within a day whatever version of lerd is running, and there is no version gate on the way in, so an old binary will happily read a definition written long after it shipped. That makes backward compatibility a property of how the schema is allowed to change rather than something a release can fix afterwards, and the pull request is the only moment to catch a change that breaks it, since a merge is on everyone's machine the next day with no way to roll it back per install.
This adds a check that flattens every document to a set of paths and types, compares the branch against what is published on main, and fails on the two changes an old binary cannot survive: a key that disappeared, and a key whose type moved under it. A value no published definition has used before comes out as a warning rather than a failure, because widening what a key accepts breaks an old switch exactly as retyping does, but only the author can say whether the binaries already out there know the new value.
Both the types and the closed value sets are inferred from the published tree itself, so there is no schema file to keep in sync as definitions grow.
The Go side of the same rule is lerd-env/lerd#1911, which makes lerd refuse a value it does not recognise instead of defaulting past it.