-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce initial version 2 and stronger versioning support for the spec #384
Conversation
🌐 Coverage report
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went back and forth through this PR a few times as it's a relatively big one, but it brings the schema patching feature. I haven't noticed anything concerning or blocking.
LGTM!
code/go/internal/spec_test.go
Outdated
@@ -14,6 +14,12 @@ import ( | |||
|
|||
func TestBundledSpecsForIntegration(t *testing.T) { | |||
fs := spec.FS() | |||
_, err := fs.Open("1/integration/spec.yml") | |||
_, err := fs.Open("integration/spec.yml") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most likely it will break the docs repository. You will need another PR to fix it. FYI it isn't a major problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I will prepare the follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have updated the pull request template in this repository, and opened PRs in the integrations and docs repositories. Also added a placeholder to avoid broken links: https://github.com/elastic/package-spec/blob/26925a80d08a39cd0d188ba81bc71b09464b1d04/versions/1/README.md
spec.go
Outdated
func CheckVersion(version *semver.Version) (*semver.Version, error) { | ||
d, err := fs.ReadFile(content, "spec/changelog.yml") | ||
if err != nil { | ||
panic(err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it safe to panic here? Is it executed only during init
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I followed the same approach as in FS()
when accessing the filesystem. But yeah, it'd be better to don't panic here.
/test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach to get a new specification version (V2) looks promising! 🚀
I've been thinking in some scenarios like removing fields (as in the license property example) or change allowed values for some property (it would be a replace operation), and it would fit perfectly 👍
README.md
Outdated
specification for a package's contents. It describes the the folder structure of packages and expected | ||
files within these folders (this is point 1. above). The specification is expressed using a schema simil | ||
ar to [JSON Schema](https://json-schema.org/), but with a couple of differences: | ||
-- The `type` field can be either `folder` or `file`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
specification for a package's contents. It describes the the folder structure of packages and expected | |
files within these folders (this is point 1. above). The specification is expressed using a schema simil | |
ar to [JSON Schema](https://json-schema.org/), but with a couple of differences: | |
-- The `type` field can be either `folder` or `file`, | |
specification for a package's contents. It describes the folder structure of packages and expected | |
files within these folders (this is point 1. above). The specification is expressed using a schema similar | |
to [JSON Schema](https://json-schema.org/), but with a couple of differences: | |
-- The `type` field can be either `folder` or `file`, |
tests := map[string]string{ | ||
"bad_duplicated_fields": "field \"event.dataset\" is defined multiple times for data stream \"wrong\", found in: ../../../../test/packages/bad_duplicated_fields/data_stream/wrong/fields/base-fields.yml, ../../../../test/packages/bad_duplicated_fields/data_stream/wrong/fields/ecs.yml", | ||
} | ||
|
||
for pkgName, expectedErrorMessage := range tests { | ||
t.Run(pkgName, func(t *testing.T) { | ||
errs := ValidateFromPath(filepath.Join("..", "..", "..", "..", "test", "packages", pkgName)) | ||
errs := ValidateFromPath(path.Join("..", "..", "..", "..", "test", "packages", pkgName)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
I have done more updates on the README to asjust the text to current structure. And added tests to ensure that possible conflicts in patches are detected for all versions defined in changelog. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
What does this PR do?
This PR introduces some changes in how versioning is done in the spec:
format_version
is strongly checked now, it must exist in the specchangelog.yml
, prereleases of the version are allowed.changelog.next.yml
file for features only enabled for next major.versions
list, with patches to apply to reconstruct older versions of the schema.license
field is removed from manifests to illustrate that.Why is it important?
To allow introducing breaking changes (or loosening validation) in a more controlled way.
Checklist
test/packages
that prove my change is effective.versions/N/changelog.yml
.Related issues