Adservice Docker image can generate an installation path that does not match its entrypoint

Description

A clean BuildKit build of src/adservice/Dockerfile can produce the application under:

/app/build/install/app/bin/AdService

However, the image entrypoint is hardcoded to:

/app/build/install/hipstershop/bin/AdService

The resulting container fails to start with:

exec: "/app/build/install/hipstershop/bin/AdService": stat /app/build/install/hipstershop/bin/AdService: no such file or directory

Suspected cause

The Dockerfile runs Gradle before copying settings.gradle:

COPY ["build.gradle", "gradlew", "./"]
COPY gradle gradle
RUN chmod +x gradlew
RUN ./gradlew downloadRepos

COPY . .
RUN ./gradlew installDist

settings.gradle defines:

rootProject.name = 'hipstershop'

Without that file during the first Gradle invocation, Gradle can initially identify /app as project app. Depending on builder and cache behavior, installDist may consequently produce build/install/app.

Reproduction evidence

• Source commit: 72ba613a05f7fcee51cf1d0badff401b6ae7074d
• Gradle: 8.14.5
• Builder: BuildKit
• Target: Linux amd64
• Observed: September 2, 2026

Inspecting the resulting image showed:

app/build/install/app/bin/AdService
app/build/install/app/bin/AdServiceClient

The image config still contained:

{"Entrypoint":["/app/build/install/hipstershop/bin/AdService"]}

For comparison, the official adservice:v0.10.6 image contains the expected build/install/hipstershop path, so the behavior appears dependent on build environment or cache behavior.

Proposed fix

Copy settings.gradle before running any Gradle command:

-COPY ["build.gradle", "gradlew", "./"]
+COPY ["build.gradle", "settings.gradle", "gradlew", "./"]

This makes the root project name available from the first Gradle invocation and ensures the generated installation path matches the existing entrypoint.