[ML] Make Appex QA/PyTorch tests version-aware on release branches

[edsavage]

Summary

Fixes the spurious PyTorch/QA build failure seen on backport PRs (e.g. build 2879 on the [9.5] backport of #3081), where the synchronous Appex QA trigger went red with:

Searching for artifacts: "build/distributions/ml-cpp-9.6.0-SNAPSHOT-linux-x86_64.zip" within step: build_test_linux-x86_64-RelWithDebInfo
buildkite-agent: fatal: failed to download artifacts: No artifacts found for downloading

Root cause

The downstream appex-qa-stateful-custom-ml-cpp-build-testing pipeline (generated by elastic/qaf-tests, pipeline_generators/local/ml-cpp-custom.py) downloads the ml-cpp artifact from the parent build (--build $BUILDKITE_TRIGGERED_FROM_BUILD_ID) but names it from STACK_VERSION, which defaults to ACTIVE_VERSIONS[0] (the current main SNAPSHOT), and builds ES from ES_BRANCH, which defaults to main. On a release-branch/backport build the parent produced ml-cpp-<release>-SNAPSHOT-... (e.g. 9.5.0), so the 9.6.0-SNAPSHOT lookup missed.

ci:run-pytorch-tests is inherited by backport PRs, so every backport hit this. It didn't block merges (the gating status is posted by the launch step; the synchronous downstream result isn't a required check), but it produced a red, misleading job on every backport.

Fix (ml-cpp side only — no qaf-tests change)

qaf-tests already supports STACK_VERSION/ES_BRANCH overrides and lists our release lines as active (main, 9.5, 9.4, 9.3, 8.19). We just need to pass the right values:

• New sourced helper .buildkite/pipelines/derive_qa_stack_env.sh:
  • STACK_VERSION ← gradle.properties elasticsearchVersion (exactly the artifact version).
  • ES_BRANCH ← main if this build's version equals ml-cpp main's version (fetched from raw.githubusercontent.com/elastic/ml-cpp/main/gradle.properties, the same host the downstream already uses), else <major>.<minor>. This is self-updating — no hard-coded "current dev minor" to bump at feature freeze. Falls back to a branch-name heuristic if that fetch fails.
  • Respects values already set (e.g. PR-comment vars GITHUB_PR_COMMENT_VAR_BRANCH/_VERSION), and writes only to stderr (the generators pipe stdout to buildkite-agent pipeline upload).
• run_pytorch_tests.yml.sh now sources the helper and forwards ES_BRANCH/STACK_VERSION into the trigger (mirroring run_qa_tests.yml.sh, which already forwarded them but had nothing to derive them).
• run_qa_tests.yml.sh sources the same helper, so QA on backports gets the same treatment.

Behaviour

• main builds: derived values equal today's defaults (main / 9.6.0) → no change.
• release-branch/backport builds: now 9.5 / 9.5.0 etc. → the parent's artifact matches and the custom ES distribution is built from the right branch.

Dry-run of the generators confirms the emitted trigger YAML:

# main:          ES_BRANCH: "main"  STACK_VERSION: "9.6.0"
# 9.5 backport:  ES_BRANCH: "9.5"   STACK_VERSION: "9.5.0"

Note

The generator scripts live in the checked-out branch, so this must be backported to 9.5/9.4/8.19 for their backport builds to benefit (same as the ci:skip-es-tests fix). Backports will follow.

Test plan

• Dry-run generators emit correct ES_BRANCH/STACK_VERSION for main and a simulated release build (done locally).
• After backporting to release branches, a real backport PR carrying ci:run-pytorch-tests triggers a downstream QA build that finds the ml-cpp-<release>-SNAPSHOT artifact and runs (no "No artifacts found").
• Confirm main-targeted PRs with ci:run-pytorch-tests are unaffected.

Made with Cursor

[elasticsearchmachine]

Pinging @elastic/ml-core (Team:ML)

[edsavage]

buildkite build