Stricter validation of field definitions#420
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
🤖 GitHub commentsExpand to view the GitHub comments
To re-run your PR in the CI, just comment with:
|
🌐 Coverage report
|
jsoriano
changed the title
|
Tested with integrations and some adjustments done. I think that the number of changes required on existing integrations now are reasonable. |
| additionalProperties: true | ||
| additionalProperties: false | ||
| patternProperties: | ||
| # Soft validation on some properties that can be present but not validated or used yet. |
There was a problem hiding this comment.
The main reason I am leaving it here is to reduce the number of changes that package developers should make to migrate to v2, and to avoid conflicts with fields copied from ECS or Beats. But these fields are not really used.
There was a problem hiding this comment.
Ok, if it is not required too many changed done by developer to migrate, it will be easier that packages get updated to 2.0.0 👍
Those could be removed in a following major if it is required.
3 participants
What does this PR do?
Stricter validation of field definitions.
Why is it important?
To reduce the risk of typos in field definitions that can lead to unexpected mappings.
Checklist
test/packagesthat prove my change is effective.spec/changelog.yml.Related issues