-
Notifications
You must be signed in to change notification settings - Fork 75
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
Adding initial spec files #1
Conversation
type: string | ||
enum: | ||
- custom | ||
default_field: |
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.
@jonathan-buttner I saw this default_field
field used here https://github.com/elastic/package-registry/blob/98d7184cfe5b1d271e1bef848a5720073959888e/testdata/package/ecs_style_dataset/0.0.1/dataset/foo/fields/fields.yml#L16. Could you tell me what it is meant for so I could appropriately describe it in this schema here? Thanks!
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.
@ycombinator I think we got rid of default_field and it was replaced by show_user and some others. So this is only here because it was not cleaned up. Found it also in other places.
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.
Sorry, ignore my comment above, just realised this is fields.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.
We can ignore this one too I think:
It is outputted by the ECS beats tooling:
https://github.com/elastic/ecs/blob/master/scripts/generators/beats_default_fields_whitelist.yml
https://github.com/elastic/ecs/blob/master/generated/beats/fields.ecs.yml#L77
I'm not even really sure what it is used for 🤷
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.
No idea at all, I think you can safely ignore/remove this field from spec.
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.
Okay, I will remove it from the spec, similar to the level
and group
fields which were removed in dd76b6d.
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.
Removed in 396721e.
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.
Versioning looks very good to me, thanks for working on it!
@ycombinator The registry running under All of this should not hold back this PR from merging. |
Co-authored-by: Massimiliano Pippi <mpippi@gmail.com>
Thanks for the explanation, @ruflin. I agree that the breaking changes should not hold back this PR. However, it means that we can't use the I looked through the comments in this PR and there are a few that are awaiting your responses. I've gathered them below for your convenience. If you could take a few minutes to respond to them, it would help move along this PR. Thanks! |
description: Base fields definitions | ||
type: file | ||
name: "base-fields.yml" | ||
required: true |
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.
Hmm can we make this required: false
the endpoint package doesn't include this file. We include the fields directly in fields.yml
. Should we allow the package developer to call the file whatever they want? Would it be easy to just validate that the directory isn't empty and that the file conforms to the fields.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.
Yeah, I'm happy to change this to whatever matches the actual usage/parsing of these files. I don't know what that is, though! Are the files merged together somehow? If so, is there some ordering/precedence taken into account while merging?
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.
The file can have any name and merging order should not matter, at least so far.
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.
Fixed in 076597f.
@jonathan-buttner One I couldn't answer in line (not sure why) was around integrations vs solution. We introduced solutions as in the beginning we expected to never show the endpoint package to users but this changed. So having it as @ycombinator I have not been very good in following up on all comments, but please do not block on me to get this in. There will be breaking changes in this spec for the upcoming Ship it. |
Many thanks to @jonathan-buttner, @mtojek, @masci, and @ruflin for reviewing this PR so thoroughly! I believe all your concerns have been addressed at this point. The initial spec in this PR may not be 100% accurate yet but I think it's in decent enough shape to get us started. I fully expect us to iterate on this in the coming weeks, especially once we start validating packages against it! To indicate that this initial spec is not quite ready for general consumption, I have done two things:
With that, I'm planning to merge this PR and then make this repository public later today. If anyone has any last-minute concerns please bring them up within the next few hours. Thank you! |
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.
Ship it!
versions/1/dataset/manifest.spec.yml
Outdated
@@ -138,5 +138,35 @@ spec: | |||
- title | |||
- description | |||
- input | |||
# https://github.com/elastic/package-registry/blob/v0.8.0/util/dataset.go#L48 |
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 believe it would be safer to refer through a commit id.
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'm actually considering removing these comments. I had put them in there for my own benefit to make sure I had accounted for most of the struct fields in the spec.
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.
Removed in ac61112.
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.
Ship it! I wonder if there is a way to enforce required fields in the spec. It might be part of the validation library.
Side note: if they are required to be present in all definitions, why don't we keep them aside from fields.yml
This PR adds specification files for the initial package specification (
format_version
= 1.0.0, which is what all packages today are using). The specification files describe:For 1. above, a schema very similar to JSON Schema is used (but written as YAML for readability), with two notable differences:
type
field can be eitherfolder
orfile
, andcontents
is introduced to (recursively) describe the contents of folders (i.e. whentype
==folder
).For 2. above, JSON Schema is used (but, again, written as YAML for readability).
Additionally, this PR adds a
README.md
file explaining the specification format.Resolves #2.
Author's TODO