[9.2](backport #47935) [beatreceiver] Add paths parameter to metricbeat module framework for auditbeat

[mergify]

Proposed commit message

This PR removes global instance of paths from auditbeat package

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works. Where relevant, I have used the stresstest.sh script to run them under stress conditions and race detector to verify their stability.
• I have added an entry in ./changelog/fragments using the changelog tool.

Disruptive User Impact

None

Related issues

• Closes [beatreceiver] replace global paths in auditbeat datastore #46992

---

This is an automatic backport of pull request #47935 done by [Mergify](https://mergify.com).

[github-actions]

🤖 GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[elasticmachine]

Pinging @elastic/obs-ds-hosted-services (Team:obs-ds-hosted-services)

[elasticmachine]

Pinging @elastic/sec-linux-platform (Team:Security-Linux Platform)

[mergify]

This pull request has not been merged yet. Could you please review and merge it @khushijain21? 🙏

[github-actions]

TL;DR

All 4 failing Buildkite jobs are failing before packaging starts due to a CI toolchain bootstrap issue (mage not installed/resolved), not due to the backported code change in this PR. Immediate fix: ensure the beats-xpack-agentbeat packaging pipeline exports/installs the expected Mage version before running .buildkite/scripts/packaging/packaging.sh.

Remediation

• In the beats-xpack-agentbeat pipeline config/hook, set ASDF_MAGE_VERSION=1.15.0 (matching other Beats pipelines) or explicitly run asdf install mage 1.15.0 before invoking packaging.
• Re-run the failed packaging jobs after the pipeline env/tool bootstrap is corrected.
• Validate by confirming mage --version succeeds in the job before mage package executes.

Investigation details

Root Cause

Classification: Configuration / CI environment issue.

All failing jobs terminate with exit 126 at the same point:

• .buildkite/scripts/packaging/packaging.sh executes mage package (.buildkite/scripts/packaging/packaging.sh:23).
• The job fails with: No preset version installed for command mage and suggests asdf install mage 1.15.0.

This indicates asdf did not have an active Mage version in that pipeline context.

Repository evidence shows the expected pattern is to provide Mage via pipeline env (for example ASDF_MAGE_VERSION: 1.15.0 appears in multiple pipeline files such as .buildkite/packaging.pipeline.yml:5, .buildkite/filebeat/filebeat-pipeline.yml:23, .buildkite/x-pack/pipeline.xpack.filebeat.yml:23).

Evidence

• Build: https://buildkite.com/elastic/beats/builds/43196
• Failed jobs (all same signature):
  • Agentbeat packaging Linux
  • Agentbeat packaging linux/amd64 FIPS
  • Agentbeat packaging linux/arm64 FIPS
  • Agentbeat packaging windows/arm64
• Key log excerpt (all 4 logs):

  ~~~ Packaging : x-pack/agentbeat
  No preset version installed for command mage
  Please install a version by running one of the following:
  asdf install mage 1.15.0
  ...
  Error: The command exited with status 126
  

Verification

• Local verification of failure path only (read-only workflow): confirmed packaging script calls mage package directly.
• No code-level unit/integration tests were run because failure is in CI bootstrap before build/test execution.

Follow-up

• If ASDF_MAGE_VERSION is already defined in the upstream beats-xpack-agentbeat pipeline, check whether that env var is being dropped/overridden in the job template or pre-command hook for these packaging steps.

Note

🔒 Integrity filtering filtered 1 item

Integrity filtering activated and filtered the following item during workflow execution.
This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.

• pr:[9.2](backport #47935) [beatreceiver] Add paths parameter to metricbeat module framework for auditbeat #49765 (pull_request_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)

---

What is this? | From workflow: PR Buildkite Detective

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[v1v]

this might also need the pin