Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 38 additions & 7 deletions .buildkite/pipelines/upload_dra_to_gcs.yml.sh
Original file line number Diff line number Diff line change
Expand Up @@ -8,20 +8,51 @@
# compliance with the Elastic License 2.0 and the foregoing additional
# limitation.
#
# Upload all artifacts, both platform-specific and all-platforms, to
# GCS, where release manager builds will download them from.
# Stage DRA artifacts and trigger unified-release DRA processing via the
# elastic/dra-prep-buildkite-plugin (replaces the Release Manager Docker step).
#

. .buildkite/scripts/common/base.sh

STACK_VERSION=$(awk -F= '/^elasticsearchVersion/ {print $2}' gradle.properties | xargs echo)

if [ -n "${VERSION_QUALIFIER:-}" ] ; then
STACK_VERSION="${STACK_VERSION}-${VERSION_QUALIFIER}"
fi

if [ -z "$BUILD_SNAPSHOT" ] ; then
BUILD_SNAPSHOT=true
fi
if [ "$BUILD_SNAPSHOT" = "true" ] ; then
DRA_WORKFLOW=snapshot
STACK_VERSION="${STACK_VERSION}-SNAPSHOT"
else
DRA_WORKFLOW=staging
fi
Comment thread
Copilot marked this conversation as resolved.

cat <<EOL
steps:
- label: ":rocket: Upload DRA artifacts to GCS :gcloud:"
key: "upload_dra_artifacts_to_gcs"
- label: ":package: DRA Prep"
key: "dra-prep"
depends_on: create_dra_artifacts
command:
- 'buildkite-agent artifact download "build/distributions/*" --step create_dra_artifacts .'
- '.buildkite/scripts/steps/upload_dra_to_gcs.sh'
command: ".buildkite/scripts/stage_artifacts.sh"
env:
DRA_WORKFLOW: "${DRA_WORKFLOW}"
agents:
provider: gcp
plugins:
- elastic/dra-prep#v0.1.5:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two related merge-gate questions:

  1. WIF — the PR notes registration in #project-stack-releases-improvements must happen before this can run. Merging without that means the next snapshot/staging DRA publish fails with no Release Manager fallback. Is WIF registered for ml-cpp yet?

  2. Plugin pinelastic/dra-prep#v0.1.5 looks fine if that's the org-recommended version. A pointer to the migration doc or another repo on the same pin would help us not drift.

Also: this step uses a vanilla GCP agent (no JDK image). Please confirm dra-prep/dractl is fully provided by the plugin on that agent — S3 still uses the JDK17 image, so it's easy to assume tools that aren't there.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WIF is already configured and it should work : https://github.com/elastic/infra/blob/ca83670976b72a26ddfe887834a5f2aae8d9c56d/terraform/providers/gcp/env/release-artifacts/elastic-release.tfvars

Plugin Pin: v0.1.5 is the current version and we will update the version if there is any change on our end to dractl.
we discussed using a floating tag (v0 or @latest) but decided to keep pinning for now as it gives us control over when product pipelines pick up dractl changes. As we will start making a bigger change to support Two-Speed Stack Release project.

dractl is installed by the plugin itself as part of its post-command hook and it does not rely on any tooling from the JDK17 image

product_id: "ml-cpp"
stack_version: "${STACK_VERSION}"
workflow: "${DRA_WORKFLOW}"

- label: ":pipeline: Trigger DRA processing"
trigger: "unified-release-dra-processing"
async: true

@edsavage edsavage Aug 19, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old GCS step ran in-pipeline, so a collect/upload failure failed the snapshot/staging build. This trigger is async: true, so the ml-cpp build can go green while DRA never lands in the final GCS path.

If that's intentional (unified-release owns retries/visibility) it's worth stating in the PR. If we still want the parent build to fail when processing fails, async: false (or an equivalent status check) is closer to the old behaviour.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @edsavage This is intentional. In the DRA-prep model, unified-release-dra-processing owns visibility, retries, and the final GCS move. The ml-cpp build’s responsibility ends once it hands off the manifest.

depends_on: "dra-prep"
build:
env:
DRA_PRODUCT_ID: "ml-cpp"
DRA_STACK_VERSION: "${STACK_VERSION}"
DRA_WORKFLOW: "${DRA_WORKFLOW}"
EOL
35 changes: 35 additions & 0 deletions .buildkite/scripts/stage_artifacts.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
#!/usr/bin/env bash
# Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
# or more contributor license agreements. Licensed under the Elastic License
# 2.0 and the following additional limitation. Functionality enabled by the
# files subject to the Elastic License 2.0 may only be used in production when
# invoked by an Elasticsearch process with a license key installed that permits
# use of machine learning features. You may not use this file except in
# compliance with the Elastic License 2.0 and the foregoing additional
# limitation.
#
# Stage DRA artifacts into artifacts/ for the elastic/dra-prep plugin.
#

set -euo pipefail

WORKFLOW="${DRA_WORKFLOW:?DRA_WORKFLOW is required}"

echo "--- :compression: Downloading ${WORKFLOW} artifacts from create_dra_artifacts step"
rm -rf build/distributions artifacts
mkdir -p build/distributions artifacts

buildkite-agent artifact download 'build/distributions/*.zip' . --step create_dra_artifacts

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

create_dra.sh still downloads Windows-style artifact paths (build\\distributions\\*.zip) when combining platform zips, and the S3 upload step uses the broader build/distributions/* glob.

This stager only downloads POSIX *.zip / *.csv. If any needed zip is stored under the backslash path in Buildkite's artifact store, DRA prep can miss it while S3 still gets it.

Could you confirm against a real snapshot build artifact listing that the combined zips + dependencies-*.csv from create_dra_artifacts are always under forward-slash paths? If not, using build/distributions/* (same as S3) then copying would be safer.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked the code in create_dra.sh and while it does download buildkite artifacts using backslash paths, the script itself is running on linux agents. If I read the code here correctly, it is combining all downloaded artifacts under a POSIX path.

buildkite-agent artifact download 'build/distributions/*.csv' . --step create_dra_artifacts

echo "--- :package: Staging ${WORKFLOW} artifacts"
cp build/distributions/*.zip artifacts/
cp build/distributions/*.csv artifacts/

if ! ls artifacts/* 1>/dev/null 2>&1; then
echo "ERROR: no ${WORKFLOW} artifacts found in artifacts/." >&2
exit 1
fi

echo "Staged artifacts:"
ls -1 artifacts/
70 changes: 0 additions & 70 deletions .buildkite/scripts/steps/upload_dra_to_gcs.sh

This file was deleted.

2 changes: 1 addition & 1 deletion dev-tools/ingest_build_timings.py
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@
"clone_eigen": "linux-x86_64",
"create_dra_artifacts": "linux-x86_64",
"upload_dra_artifacts": "linux-x86_64",
"upload_dra_artifacts_to_gcs": "linux-x86_64",
"dra-prep": "linux-x86_64",
}


Expand Down
Loading