💔 Build Failed

• Buildkite Build
• Commit: 5dfd5fd

Failed CI Steps

• Check integrations abnormal_security
• Check integrations aws_bedrock
• Check integrations crowdstrike
• Check integrations etcd
• Check integrations nvidia_gpu
• Check integrations php_fpm

History

cc @jsoriano @andrewkroh

These are the failures:

abnormal_security.ai_security_mailbox_not_analyzed

• Package policy is invalid: inputs.cel.streams.abnormal_security.ai_security_mailbox_not_analyzed.vars.wait_interval: Recent Message Grace Interval is required

aws_bedrock.invocation

• Package policy is invalid: inputs.aws-s3.streams.aws_bedrock.invocation.vars.file_selectors: Invalid format for File Selectors: expected array

crowdstrike.fdr

• Package policy is invalid: inputs.aws-s3.streams.crowdstrike.fdr.vars.queue_url: Queue URL is required

nvidia_gpu.stats

• Package policy is invalid: inputs.prometheus/metrics.streams.nvidia_gpu.stats.vars.ssl: Invalid format for SSL Configuration: expected array

I believe that these failures represent the correct behavior for a system test that doesn't define a required variable. I find it surprising that the Fleet API permits null values (e.g., {"vars":{"proxy_url":{"value":null,"type":"url"}}}) to meet the required variable constraint¹. The specification doesn't specify that "required" means non-null, so this behavior is acceptable. However, most systems I'm familiar with include an explicit nullable property that's disabled by default (as seen in JSON Schema, OpenAPI, and Terraform variables), meaning required variables must be non-null unless null has been explicitly allowed.

I think the solution should involve updating these system tests to define the required variables they intend to use during testing. They can continue using null, but they must explicitly set it in their system test configuration, such as wait_interval: null. We can continue with elastic/elastic-package#2980 as long as we update the 4 system tests before the elastic-package version bump.

I think the solution should involve updating these system tests to define the required variables they intend to use during testing. They can continue using null, but they must explicitly set it in their system test configuration, such as wait_interval: null. We can continue with elastic/elastic-package#2980 as long as we update the 4 system tests before the elastic-package version bump.

Agree, let's continue with elastic/elastic-package#2980.