Closed mrodm closed 1 month ago
test integrations
Created or updated PR in integrations repository to test this version. Check https://github.com/elastic/integrations/pull/11304
Just as a note, this new validation rule will affect all packages independently of their package spec version or package type @jsoriano
With the latest execution of "test integrations" , there were two packages that would fail "aws" and "network_traffic".
I'll check which packages running "test integrations" once more.
test integrations
Created or updated PR in integrations repository to test this version. Check https://github.com/elastic/integrations/pull/11304
cc @mrodm
Currently these are the packages failing due to package-spec related errors:
Build: https://buildkite.com/elastic/integrations/builds/16755
- aws: new version check
- network_traffic: new version check
I guess these can be solved by fixing the order in the changelog? I think it would be fine to do that when we update elastic-package in integrations.
- elastic_connectors: missing new fields
Not related to this PR (but to https://github.com/elastic/package-spec/pull/801), and this is known by the package owners, to be fixed when updating elastic-package.
I think we can go on with this change.
There is already a PR open to fix AWS changelog https://github.com/elastic/integrations/pull/11307
- aws: new version check
- network_traffic: new version check
I guess these can be solved by fixing the order in the changelog? I think it would be fine to do that when we update elastic-package in integrations.
In case for instance of network_traffic, it has this version as the least 1.31.1, and the second one is 1.32.0. If it is re-ordered, 1.32.0 would have less changes/"code" than 1.31.1 version.
Another option would be to release a new version 1.32.1 with the same contents as 1.31.1. Not sure what it could be set in the changelog entry for this. Probably the same data as in 1.31.1?
Another option would be to release a new version 1.32.1 with the same contents as 1.31.1. Not sure what it could be set in the changelog entry for this. Probably the same data as in 1.31.1?
Yes, actually 1.32.0 will be "reverting" the change in 1.31.1. This was actually asked after merging. https://github.com/elastic/integrations/pull/10800#issuecomment-2325463137
The changelog could be fixed to something like this:
- version: "1.32.1"
changes:
- description: Add `event.module` to datastreams
type: bugfix
link: https://github.com/elastic/integrations/pull/10800
- version: "1.32.0"
changes:
- description: `event.module` is not included in datastreams, this is an unexpected regression.
type: breaking-change
link: https://github.com/elastic/integrations/pull/10800
- version: "1.31.1"
changes:
- description: Add `event.module` to datastreams
type: bugfix
link: https://github.com/elastic/integrations/pull/10800
- description: Set `map_to_ecs` to enabled by default
type: enhancement
link: https://github.com/elastic/integrations/pull/10785
PR open with the change I am propossing for network traffic: https://github.com/elastic/integrations/pull/11322
What does this PR do?
Add a new validation check to ensure that the first (newer) changelog entry defined in the changelog file is not lower than the other versions.
Example of PR releasing an old version: https://github.com/elastic/integrations/pull/10800
Why is it important?
Ensure that it is not released a older version. Releasing an older version should be performed through another mechanism.
Checklist
test/packages
that prove my change is effective.spec/changelog.yml
.Related issues
-