diff --git a/.buildkite/pipeline.trigger.compliance.tests.sh b/.buildkite/pipeline.trigger.compliance.tests.sh index 408be54b9..a50176aba 100755 --- a/.buildkite/pipeline.trigger.compliance.tests.sh +++ b/.buildkite/pipeline.trigger.compliance.tests.sh @@ -28,7 +28,7 @@ steps: EOF # Generate each test we want to do. -compliance_test 9.4.0-SNAPSHOT 3.6.0 +compliance_test 9.4.0-SNAPSHOT 3.6.1 compliance_test 8.19.3 3.4.2 compliance_test 9.0.6 3.3.5 compliance_test 8.14.0 3.1.5 diff --git a/.go-version b/.go-version index e6a6e7cd3..0e0c284d8 100644 --- a/.go-version +++ b/.go-version @@ -1 +1 @@ -1.25.8 +1.25.9 diff --git a/AGENTS.md b/AGENTS.md index 16b14dbca..3232774b3 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -231,11 +231,11 @@ go run github.com/elastic/elastic-package stack up -d --version 9.4.0-SNAPSHOT eval $(go run github.com/elastic/elastic-package stack shellinit) cd .. -# Run compliance tests against spec version 3.6.0 -TEST_SPEC_VERSION=3.6.0 make -C compliance test +# Run compliance tests against spec version 3.6.1 +TEST_SPEC_VERSION=3.6.1 make -C compliance test # Run only specific feature files (comma-separated, paths relative to compliance/) -TEST_SPEC_VERSION=3.6.0 TEST_SPEC_FEATURES=features/basic.feature,features/package-dependencies.feature make -C compliance test +TEST_SPEC_VERSION=3.6.1 TEST_SPEC_FEATURES=features/basic.feature,features/package-dependencies.feature make -C compliance test # Stop the stack when done cd compliance && go run github.com/elastic/elastic-package stack down @@ -250,7 +250,7 @@ export ELASTICSEARCH_USERNAME=elastic export ELASTICSEARCH_PASSWORD=changeme export KIBANA_HOST=https://localhost:5601 export CA_CERT=/path/to/ca.crt # only if needed -TEST_SPEC_VERSION=3.6.0 make -C compliance test +TEST_SPEC_VERSION=3.6.1 make -C compliance test ``` CI version combinations (stack version ↔ spec version) are in @@ -383,12 +383,12 @@ func TestValidateMyRule(t *testing.T) { }{ "valid": { manifest: `name: test -format_version: 3.6.0`, +format_version: 3.6.1`, expectError: false, }, "invalid": { manifest: `name: test -format_version: 3.6.0 +format_version: 3.6.1 invalid_field: value`, expectError: true, errorContains: "invalid_field", @@ -447,7 +447,7 @@ In `code/go/internal/validator/spec.go`: { Func: semantic.ValidateMyRule, Type: spectypes.Integration, - Version: semver.MustParse("3.6.0"), + Version: semver.MustParse("3.6.1"), } ``` diff --git a/compliance/features/dataset.feature b/compliance/features/dataset.feature index d1d89ced1..1fd1aad1c 100644 --- a/compliance/features/dataset.feature +++ b/compliance/features/dataset.feature @@ -46,8 +46,6 @@ Feature: Data stream dataset configuration And there is an index template "metrics-custom.otel_test" with pattern "metrics-custom.otel_test.otel-*" @3.6.0 - @skip - # Pending dataset routing fix for dynamic_signal_types: https://github.com/elastic/kibana/pull/262000 Scenario: Input OTel package with dynamic signal types uses default dataset Given the "dataset_input_otel_dynamic" package is installed And a policy is created with "dataset_input_otel_dynamic" package, "0.0.1" version, "otel_receiver" template, "otel_receiver" input, "otelcol" input type and dataset "" @@ -57,8 +55,6 @@ Feature: Data stream dataset configuration And there is an index template "traces-otel_receiver" with pattern "traces-otel_receiver.otel-*" @3.6.0 - @skip - # Pending dataset routing fix for dynamic_signal_types: https://github.com/elastic/kibana/pull/262000 Scenario: Input OTel package with dynamic signal types dataset can be overridden Given the "dataset_input_otel_dynamic" package is installed And a policy is created with "dataset_input_otel_dynamic" package, "0.0.1" version, "otel_receiver" template, "otel_receiver" input, "otelcol" input type and dataset "custom.dynamic_test" @@ -68,8 +64,6 @@ Feature: Data stream dataset configuration And there is an index template "traces-custom.dynamic_test" with pattern "traces-custom.dynamic_test.otel-*" @3.6.0 - @skip - # Pending dataset routing fix for dynamic_signal_types: https://github.com/elastic/kibana/pull/262000 Scenario: Input OTel package with dynamic signal types and dataset variable uses developer default Given the "dataset_input_otel_dynamic_generic" package is installed And a policy is created with "dataset_input_otel_dynamic_generic" package, "0.0.1" version, "otel_receiver" template, "otel_receiver" input, "otelcol" input type and dataset "" diff --git a/spec/changelog.yml b/spec/changelog.yml index e5e1afda2..78fd45666 100644 --- a/spec/changelog.yml +++ b/spec/changelog.yml @@ -8,14 +8,7 @@ - description: Add support for semantic_text field definition. type: enhancement link: https://github.com/elastic/package-spec/pull/807 - # pending on https://github.com/elastic/kibana/pull/262129 - - description: Add top-level `sections` list for defining named section headers, and `section` attribute on vars for assigning variables to a section in the Fleet UI. - type: enhancement - link: https://github.com/elastic/package-spec/pull/1133 - - description: Add `show_divider` optional boolean to input objects to suppress horizontal dividers in the Fleet UI. - type: enhancement - link: https://github.com/elastic/package-spec/pull/1133 -- version: 3.6.1-next +- version: 3.6.1 changes: - description: Add var_groups support to policy template and input levels in integration packages, and to policy template and package root levels in input packages. type: enhancement @@ -36,6 +29,12 @@ - description: Allow _dev/build/docs folder in content packages to support README auto-generation. type: enhancement link: https://github.com/elastic/package-spec/pull/1144 + - description: Add top-level `sections` list for defining named section headers, and `section` attribute on vars for assigning variables to a section in the Fleet UI. + type: enhancement + link: https://github.com/elastic/package-spec/pull/1133 + - description: Add `show_divider` optional boolean to input objects to suppress horizontal dividers in the Fleet UI. + type: enhancement + link: https://github.com/elastic/package-spec/pull/1133 - version: 3.6.0 changes: - description: Add pipeline tag validations.