Skip to content

fix(docker): build the client on the host and make utils/docker the build context - #2034

Merged
Yury Semikhatsky (yury-s) merged 9 commits into
microsoft:mainfrom
yury-s:fix-docker-source-layer
Nov 4, 2026
Merged

Yury Semikhatsky (yury-s) merged 9 commits into
microsoft:mainfrom
yury-s:fix-docker-source-layer

Conversation

@yury-s

@yury-s Yury Semikhatsky (yury-s) commented Nov 3, 2026 •

Copy link
Copy Markdown
Member

Summary

  • Like the other language ports, utils/docker/build.sh builds the client on the host and stages the client jar and its runtime dependencies under utils/docker/dist/. utils/docker is the Docker build context, so the repository never reaches the image.
  • The Dockerfiles bind-mount dist/ only to run the CLI that installs the driver, the browsers and their dependencies; the client itself is not baked into the image, and the image needs no Maven settings secret.
  • utils/docker/.dockerignore admits only dist/ and maven/, and keeps the explicit VCS and credential exclusions.
  • The Docker workflow copies the SNAPSHOT artifacts that build.sh installed on the runner into the container for the tests.

… stage

- Send only the build inputs to the Docker build context: .dockerignore is
  an allowlist, which keeps VCS metadata and CI-written files out of it.
- Bind-mount the build context into a separate builder stage instead of
  COPYing it. The final stage gets only the playwright-java artifacts of
  the local Maven repository and runs the CLI from a bind mount of the
  builder's classes and runtime dependencies.
…uild context

Like the other language ports, build.sh builds the client on the host and
stages what the image needs under utils/docker/dist: the playwright-java
artifacts for the local Maven repository and the CLI jars. The Dockerfiles
COPY the former and run the CLI from a bind mount of the latter, so the
image no longer builds from source and the repository is not part of the
build context. The root .dockerignore is no longer needed.
…gnore the rest of the context

Reword the pipeline comments for the client build on the host, and add a
.dockerignore for the utils/docker build context that admits only dist/
and maven/.
@yury-s Yury Semikhatsky (yury-s) changed the title fix(docker): build the image from an allowlisted context in a builder stage fix(docker): build the client on the host and make utils/docker the build context Nov 4, 2026
- Drop MAVEN_SETTINGS_SECRET: the host build reads ~/.m2/settings.xml, which
  is where the pipeline puts the authenticated settings anyway.
- Read the project version and the local repository in one exec:exec call,
  the plugin pom.xml pins, like publish_docker.sh does.
- Fold mkdir /ms-playwright into the CLI step, run install --with-deps
  instead of install-deps and install, and drop the redundant
  DEBIAN_FRONTEND prefix.
- Ignore utils/docker/dist in utils/docker/.gitignore next to oras.
Like the other language ports, the image ships the runtime, the browsers
and their dependencies; the client comes from the user's own build. The
staged client jars are only mounted to run the CLI, and /root/.m2 is gone
from the image. The Docker workflow copies the SNAPSHOT artifacts that
build.sh installed on the runner into the container for the tests.
The comments described the settings as mirroring Maven Central to the
DevDiv_PublicPackages feed. They route every download through the feed instead
of Maven Central, as the settings file itself says.
Comment thread scripts/NODE_VERSION Resolved
Comment thread .azure-pipelines/publish-docker.yml Resolved
The Maven settings are explained where they are copied, and build.sh describes
how it uses them.
@yury-s
Yury Semikhatsky (yury-s) merged commit be0cf6d into microsoft:main Nov 4, 2026
18 of 20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants