[WIP] Run exhaustive tests on arm linux

[donoghuc]

Add cells to the existing aarch64 pipeline to run exhaustive tests on arm arch. This starts with two POC bits. 1. build a .deb from the current checkout and test it.
2. download an artifact built by DRA and test it. Based on this POC we can work through what needs to be expanded to get full coverage.

[github-actions]

🤖 GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)
• /run exhaustive tests : Run the exhaustive tests Buildkite pipeline.

[mergify]

This pull request does not have a backport label. Could you fix it @donoghuc? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit.
• If no backport is necessary, please add the backport-skip label

[donoghuc]

This PR illustrates some examples of additional testing for consideration in LS CI.

1. WIth the Exhaustive Acceptance Tests (Built from source) pipeline we build an artifact (in this case deb) and test it on aarch64. We currently have no exhaustive tests running on aarch64 VMs. We can mirror what we do for exhaustive tests on x86_64 VMs (we can build in one step (even on x86_64 to mimic dra) and then install/test on a set of VMs. At minimum it should be linux-aarch 64 and macos-aarch64 (assuming we can get those resources in CI).

   The test run for https://buildkite.com/elastic/logstash-aarch64-pipeline/builds/621#019c2f47-01d1-46e1-bc0d-34cd08baeefc shows that it is possible for the exhaustive tests to run succesfully against aarch64 linux (deb). NOTE this works because the .deb is built ON and aarch64 machine (and therefore is not susceptible to the bug).

2. For the approach in 1 we get the benefit of building on HEAD of whatever branch is being tested. This is often desirable, BUT it does not actually test artifacts created by DRA. The Exhaustive Acceptance Tests (Released 9.3.0) pipeline shows a pattern for testing against a package built with DRA. For this approach I propose we come up with a scheduled job (more frequent for SNAPSHOT builds and ONCE for released versions) where a matrix of active logstash versions are tested (exhaustive tests) against a representative set of VMs. For this it would include aarch: linux (rpm, deb, tar), osx (tar) and x86: windows (x86), linux (rpm, deb, tar), and osx (tar). This would catch issues with DRA artifacts (a layer that does not exist today).

   The test run for https://buildkite.com/elastic/logstash-aarch64-pipeline/builds/621#019c2f47-01d3-47e1-b357-df9952649946 shows the expected failure for downloading 9.3.0 (showing this would have caught the packaging bug)

2026-02-05 11:40:40 PST | +Using bundled JDK: /usr/share/logstash/jdk
-- | --
2026-02-05 11:40:40 PST | +/usr/share/logstash/bin/logstash-plugin: 1: exec: /usr/share/logstash/jdk/bin/java: Exec format error

What would be needed:

1. Vet we have suitable VMs (linux distro flavors (rpm, deb) aarch and x86, windows x86, mac x86 aarch)
2. Enhance acceptance test helpers to be able to install/run .tar artifacts on windows/mac/linux

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: f3ae35a