Import ecs fields from the ecs_nested.yml source file #766
Conversation
| @@ -1,6 +1,4 @@ | |||
| - name: destination.geo.location | |||
| external: ecs | |||
| - name: geo.location | |||
| external: ecs | |||
There was a problem hiding this comment.
This field is actually invalid, as reported in #750.
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
🤖 GitHub commentsTo re-run your PR in the CI, just comment with:
|
|
/test |
jsoriano
changed the title
@mtojek take into account that this is for the fields imported for the The mention to beats is because before this change we are using the ecs fields document generated for beats (like this one), and after this change we would be using one of the generic ones (like this one). This way we can import anything from the ECS definitions, and not only what is relevant to Beats. I guess we don't want to get rid of |
internal/fields/model.go
Outdated
| case yaml.MappingNode: | ||
| // Fields are defined as a map, this happens in ecs fields files. | ||
| var fields []FieldDefinition | ||
| for i := 0; i < len(value.Content); i += 2 { |
There was a problem hiding this comment.
Is it safe to assume it's always a pair? Is there a chance that it will become a triple :)? a comment, or second value...
There was a problem hiding this comment.
In principle yes, the content of a mapping node should be pairs of key/values. Comments are included in the significative nodes themselves.
But let me add an additional constraint here to avoid reading the last i+1 value when it doesn't exist.
Import ECS fields from
ecs/ecs_nested.ymlinstead of frombeats/fields.ecs.yml.Beats fields don't include all the information provided by ECS, for example they don't include the
normalizerules, required for #615. I guess this can be expected, as there can be features of ECS that are not used or needed in Beats, but could be used by other tools.ecs_nested.ymltakes into account where nested objects can be reused. This fixes #750.