Prepare release 3.6.3#1168
Conversation
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
📝 WalkthroughWalkthroughAdds a minimal OpenTelemetry test package (manifests, streams, fields, README, changelog), enables a compliance scenario using it, centralizes policy-creation helpers with input-effective-name support, bumps spec to 3.6.3 in changelog and Buildkite, and inserts a release workflow step to review pending TODOs. ChangesOTel compliance package and feature test
Spec Version 3.6.3 Release Update
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
teresaromero
left a comment
There was a problem hiding this comment.
I think we need to fix good_v3 agentless deployment modes as its the shared package for the compliance tests. From claudes investigation:
Single root cause (shared by both jobs)
compliance_test.go runs 27 scenarios; 26 pass, 1 fails — the same one in both stack versions:
Scenario: Integration package with OTel input can be installed # features/basic.feature:39
And a policy is created with "good_v3" package, "1.1.0" version,
"otel" template, "otel_logs" input, "otelcol" input type and dataset ""
Error: failed to create package policy: request failed with status 400, body:
{"statusCode":400,"error":"Bad Request",
"message":"Input aws/s3 in good_v3 is not allowed for deployment mode 'default'"}
Why this is happening
This scenario was un-skipped on this branch in 709e41a — "Enable named inputs compliance test now that blockers are merged" (the named-inputs
blockers were package-spec#1135 and kibana#262138).
The test creates a policy for the otel policy template in good_v3 (test/packages/good_v3/manifest.yml:160). The package also defines an
apache-agentless template (line 116) whose aws/s3 input is restricted to deployment_modes: ['agentless'] (line 149-152). Kibana 9.4.0 and
9.5.0-SNAPSHOT are rejecting the request because they validate the package's aws/s3 input against the policy's deployment mode (default) — even
though that input belongs to a different policy template that the test isn't using.
So the "blockers merged" assumption in 709e41a doesn't hold for these stack versions: either the corresponding Kibana fix hasn't actually
landed in 9.4.0 / today's 9.5.0-SNAPSHOT, or it only handles named inputs but not the cross-template deployment-mode check that the existing
fixture exercises.
…scenario good_v3 cannot be used for this scenario because it has a secondary policy template (apache-agentless) with an input annotated as deployment_modes: ['agentless']. Kibana's simplified package-policy API validates all package inputs regardless of the targeted template, causing a spurious 400 when creating a non-agentless policy for the otel template. The new compliance-only package is a minimal integration with a single otel policy template and an otel_logs data stream, avoiding the cross-template validation issue. Co-authored-by: Cursor <cursoragent@cursor.com>
…c/kibana#268930) Co-authored-by: Cursor <cursoragent@cursor.com>
|
Issue created about this: elastic/kibana#268930 I am leaving |
| title: OTel logs | ||
| description: Collect logs via OTel receiver | ||
| inputs: | ||
| - type: otelcol |
There was a problem hiding this comment.
There should be two otelcol inputs here, to actually check resolution of ambiguous names, adding it.
There was a problem hiding this comment.
Ah no, this cannot work yet, till compliance tests build packages with an elastic-package with elastic/elastic-package#3480.
I will add the second input after elastic-package is released and used here.
…ance test Add a second named otelcol input (otel_metrics) to the good_integration_otel package so it has two inputs of the same type, exercising the qualified input names feature from package-spec#1135 / kibana#262138. Add a new compliance step variant that takes an explicit input effective name (Fleet's term: name ?? type) to build the correct simplified policy inputs key for named inputs. The index template .otel suffix assertion is kept but skipped pending a Kibana fix for named otelcol inputs not getting the suffix (kibana#268930). Co-authored-by: Cursor <cursoragent@cursor.com>
Remove createPolicyForPackage (duplicated orchestration) in favour of createPolicyForPackageInputAndDataset with empty input parameters. Extract withAgentPolicyID helper to remove the repeated NewKibanaClient/call/context.WithValue skeleton from the three step handlers. Co-authored-by: Cursor <cursoragent@cursor.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@compliance/kibana.go`:
- Around line 268-269: The code builds policyInputName using inputEffectiveName
without ensuring it's non-empty; update the guard that checks templateName,
inputName, and inputType to also verify inputEffectiveName != "" (or add an
explicit early-return/skip when inputEffectiveName is empty) before computing
policyInputName so you never produce "templateName-"; adjust any downstream
logic to handle the new early-return/skip if applicable.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: d75c4d3f-68fb-42a1-bb6a-3e529cf7bc22
⛔ Files ignored due to path filters (1)
test/packages/good_integration_otel/img/sample-logo.svgis excluded by!**/*.svg
📒 Files selected for processing (17)
.buildkite/pipeline.trigger.compliance.tests.sh.cursor/skills/package-spec-release/references/workflow.mdcode/go/pkg/validator/validator_test.gocompliance/compliance_test.gocompliance/features/basic.featurecompliance/kibana.gospec/changelog.ymltest/packages/good_integration_otel/changelog.ymltest/packages/good_integration_otel/data_stream/otel_logs/agent/stream/stream.yml.hbstest/packages/good_integration_otel/data_stream/otel_logs/fields/base-fields.ymltest/packages/good_integration_otel/data_stream/otel_logs/manifest.ymltest/packages/good_integration_otel/data_stream/otel_metrics/agent/stream/stream.yml.hbstest/packages/good_integration_otel/data_stream/otel_metrics/fields/base-fields.ymltest/packages/good_integration_otel/data_stream/otel_metrics/manifest.ymltest/packages/good_integration_otel/docs/README.mdtest/packages/good_integration_otel/manifest.ymltest/packages/good_v3/manifest.yml
| if templateName != "" && inputName != "" && inputType != "" { | ||
| policyInputName := templateName + "-" + inputType | ||
| policyInputName := templateName + "-" + inputEffectiveName |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | ⚡ Quick win
Consider validating inputEffectiveName when building the policy input name.
The conditional on line 268 checks that templateName, inputName, and inputType are non-empty, but line 269 uses inputEffectiveName without verifying it's non-empty. If inputEffectiveName were empty, policyInputName would become "templateName-".
While the function comment indicates inputEffectiveName should always be valid when the other parameters are provided, an explicit guard would improve robustness.
🛡️ Suggested validation
- if templateName != "" && inputName != "" && inputType != "" {
+ if templateName != "" && inputName != "" && inputType != "" && inputEffectiveName != "" {
policyInputName := templateName + "-" + inputEffectiveName📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if templateName != "" && inputName != "" && inputType != "" { | |
| policyInputName := templateName + "-" + inputType | |
| policyInputName := templateName + "-" + inputEffectiveName | |
| if templateName != "" && inputName != "" && inputType != "" && inputEffectiveName != "" { | |
| policyInputName := templateName + "-" + inputEffectiveName |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@compliance/kibana.go` around lines 268 - 269, The code builds policyInputName
using inputEffectiveName without ensuring it's non-empty; update the guard that
checks templateName, inputName, and inputType to also verify inputEffectiveName
!= "" (or add an explicit early-return/skip when inputEffectiveName is empty)
before computing policyInputName so you never produce "templateName-"; adjust
any downstream logic to handle the new early-return/skip if applicable.
💚 Build Succeeded
History
|
What does this PR do?
Prepares the release of package-spec 3.6.3.
Changes in this release:
releasefield to agentless deployment mode to explicitly declare its release stage. (#1130)Why is it important?
Cuts the 3.6.3 patch release so that packages can use the new
releasefield in agentless deployment mode.Checklist
[ ] I have added test packages totest/packagesthat prove my change is effective.spec/changelog.yml.Related issues
Made with Cursor
Summary by CodeRabbit
Chores
New Features
Documentation
Tests