What works elsewhere:

Local Docker Compose: additional_contexts.aws: ~/.aws works as expected.

GitHub Actions: docker/build-push-action@v6 with build-contexts: aws=backend/python/docker/ci-aws works as expected.

What fails on Harness Cloud:

Failure mode 1 — caching: false (plain docker build)

With caching: false, build logs show plain docker build (no buildx, no --build-context). BuildKit then resolves from=aws as a Docker Hub image:

#6 [internal] load metadata for docker.io/library/aws:latest

#6 ERROR: pull access denied, repository does not exist or may require authorization

Base image stages without from=aws succeed; service image stages that use the named context fail.

Failure mode 2 — caching: true + PLUGIN_BUILDX_OPTIONS

Per your docs, caching: true enables buildx, and named contexts should be passed via PLUGIN_BUILDX_OPTIONS. We configured:

caching: true

envVariables:

PLUGIN_BUILDX_OPTIONS: "--build-context aws=/harness/backend/python/docker/ci-aws"

Build fails immediately with:

unknown flag: --build-context aws

Usage: docker buildx build [OPTIONS] PATH | URL | -

It appears Harness splits PLUGIN_BUILDX_OPTIONS on =, so --build-context aws=/harness/... becomes an invalid flag --build-context aws (path dropped).

A prepare step runs before the build and writes credentials to /harness/backend/python/docker/ci-aws/ (verified present on the VM).

Failure mode 3 — buildAdditionalContext YAML field

We also tried (not in your published BuildAndPushECR docs):

caching: true

buildAdditionalContext:

aws: backend/python/docker/ci-aws

Same docker.io/library/aws:latest error as failure mode 1 — suggests the field is ignored or not wired to the drone-docker/buildx plugin on Harness Cloud.

Questions for Harness:

What is the supported, documented way to pass Docker BuildKit named build contexts (--build-context name=path) from a BuildAndPushECR step on Harness Cloud?

Is buildAdditionalContext a valid field for BuildAndPushECR? If yes, what is the correct schema, and which build infrastructures/plugin versions support it?

Is the PLUGIN_BUILDX_OPTIONS = splitting behavior a known bug? Is there a workaround (e.g. PLUGIN_BUILDX_OPTIONS_SEMICOLON, stage variables, or another env var) to pass --build-context aws=/harness/... intact?

Does PLUGIN_BUILDX_OPTIONS_SEMICOLON work on Harness Cloud for this use case, or is it only for comma-containing values like --output=type=tar,dest=...?

Are named build contexts supported only on Kubernetes build infra (e.g. with CI_USE_BUILDX_ON_K8), and not on Harness Cloud?