Add JSON patch to remove SLO assets for spec versions less than 3.4.0#884
Conversation
| errors: | ||
| exclude_checks: | ||
| - PSR00001 # Allow to use unreleased features in GA package. |
There was a problem hiding this comment.
Added since 3.4.0 is not released yet (-next prerelease tag)
| @@ -1,4 +1,4 @@ | |||
| format_version: 3.3.1 | |||
| format_version: 3.4.0 | |||
There was a problem hiding this comment.
Should it be updated the spec version for the compliance test here ?
package-spec/compliance/features/basic.feature
Lines 16 to 19 in 4366bf7
That test is running successfully even if that spec version is not updated.
There was a problem hiding this comment.
If the package has SLOs it should be updated, yes.
There was a problem hiding this comment.
If that spec version is updated to be @3.4.0, I guess it should be needed to add a new compliance test for 3.4.0.
Or should it be updated the one with stack 9.1.0-SNAPSHOT to 3.4.0 ? @jsoriano
Would it be better to create a new content package without SLO , so it can be tested that scenario with previous spec versions 3.3.0 ?
There was a problem hiding this comment.
Added a new basic_content test package , to be able to keep testing content packages with spec version 3.3.0 (and previous Elastic stacks). Added in 6250bd1
|
test integrations |
|
Created or updated PR in integrations repository to test this version. Check elastic/integrations#13242 |
| @@ -1,4 +1,4 @@ | |||
| format_version: 3.3.1 | |||
| format_version: 3.4.0 | |||
There was a problem hiding this comment.
If the package has SLOs it should be updated, yes.
| {fn: semantic.ValidateKibanaNoDanglingObjectIDs, since: semver.MustParse("3.0.0")}, | ||
| {fn: semantic.ValidateKibanaFilterPresent, since: semver.MustParse("3.0.0")}, | ||
| {fn: semantic.ValidateKibanaNoLegacyVisualizations, types: []string{"integration"}, since: semver.MustParse("3.0.0")}, | ||
| {fn: semantic.ValidateKibanaNoLegacyVisualizations, types: []string{"integration", "content"}, since: semver.MustParse("3.0.0")}, |
There was a problem hiding this comment.
Should these changes be mentioned in the changelog too?
There was a problem hiding this comment.
Added a new changelog entry for these changes in dd33139
|
Validated in elastic/integrations#13242 that testing of the current content packages ( Buildkite build: https://buildkite.com/elastic/integrations/builds/23702 |
| EOF | ||
|
|
||
| # Generate each test we want to do. | ||
| compliance_test 9.1.0-SNAPSHOT 3.4.0 |
There was a problem hiding this comment.
This would allow to test the installation of good_content package that contains SLO assets.
@3.4.0
Scenario: Content package can be installed
Given the "good_content" package is installed
#Then there are no errors.
Does it make sense?
There was a problem hiding this comment.
Or maybe, just use the new basic_content package for compliance testing and remove the testing of good_content (this contains SLO assets)?
If good_content package is removed from these tests, there is no need to add this new compliance test with spec 3.4.0.
There was a problem hiding this comment.
Compliance tests for 3.4.0 in 9.1.0 should fail, because 3.4.0 is not implemented yet. Or is it?
There was a problem hiding this comment.
It's not failing the current compliance tests, but I don't see any SLO assets created when I tested locally to install in Elastic stack 9.1.0-SNAPSHOT (related PR not merged yet elastic/kibana#186974).
There was a problem hiding this comment.
It has been updated the compliance test using the good_content package to validate that there is a specific SLO asset installed. Currently, it's failing when using spec 3.4.0 and latest Elastic stack 9.1.0-SNAPSHOT.
https://buildkite.com/elastic/package-spec/builds/1053#0195c88d-3a38-44db-a668-f1c14f0cf477
Therefore, I will remove the compliance test for that scenario (9.1.0-SNAPSHOT and spec 3.4.0): 5b59414
💚 Build Succeeded
History
cc @mrodm |
What does this PR do?
Remove SLO assets in content package for spec versions
< 3.4.0, as it is applied in the integration packages.Ensure that all the kibana validation rules are also executed in content packages.
Why is it important?
Keep the same behavior in content and integration packages.
Checklist
test/packagesthat prove my change is effective.spec/changelog.yml.Related issues