Dockerfile_local

Dockerfile_local is the CI Dockerfile with the parts that only work on a Jenkins agent removed, so it builds on a laptop. Upstream example (Go service): https://git.netcracker.com/PROD.INMRND.UNM/object-group-manager/-/blob/master/Dockerfile_local

Create one only when the plain Dockerfile fails locally. ndo-ship.sh picks Dockerfile_local automatically when present, otherwise falls back to Dockerfile.

What to strip from the CI Dockerfile

COPY/ADD of shared resources, config bundles, or licence files injected by the pipeline.
ARGs the pipeline fills (DB hosts, wiremock hosts, credentials) — hardcode a dev value or drop the stage.
Integration/test stages that need Mongo/Postgres/Arango/Kafka. Keep pure unit tests only, or run tests outside Docker.
test-report / coverage export stages — dead weight for a repro image.

What must stay

A stage named release — ndo-ship.sh builds --target release when the dockerfile has stages.
The runtime base image and every COPY that puts the binary/jar plus its runtime resources in place.

Java / Maven services (CIM, device-library, …)

Their Dockerfile is single-stage and copies a prebuilt jar:

COPY --chown=10001:10001 target/consolidated-inventory-manager*.jar /app/app.jar

ndo-ship.sh detects pom.xml + a COPY … target/ line and runs mvn -B -DskipTests package before docker build, so the jar exists. No Dockerfile_local is needed unless the base image or an apk mirror is unreachable from the laptop.

If the apk add step fails (internal yumsrv03cn mirror unreachable off-VPN), that layer only installs fonts — a Dockerfile_local that drops it is fine for a repro image:

FROM artifactorycn.netcracker.com:17003/alpine/openjdk17:17.0.18.8.03 AS release
USER root
COPY --chown=10001:10001 target/consolidated-inventory-manager*.jar /app/app.jar
USER 10001:10001
CMD ["java", "-jar", "/app/app.jar"]

A working example that built and deployed cleanly is kept alongside this file: bom-Dockerfile_local.example (business-operation-manager, verified 2026-08-12).

Go services (BOM, monitoring-*, …)

Already multi-stage with base / test / build / release. The usual local-only edits: drop the test stage's external ARG hosts, and drop COPY … /shared_resources if the pipeline generates it.

The Go build stages already pin GOARCH=amd64, so they cross-compile fine, but the runtime stage still needs --platform linux/amd64 (see below).

Architecture — the trap

The Mac is arm64; the clusters are amd64. Without --platform linux/amd64 the image builds and pushes fine, then the pod dies with exec format error or no match for platform in manifest. ndo-ship.sh passes --platform linux/amd64 by default; do not remove it.

An amd64 build on an arm64 host runs under emulation, so the maven/go steps inside Docker are slow. That is why ndo-ship.sh runs Maven natively on the host and only the image assembly under Docker.

Registry

artifactorycn.netcracker.com:17009 is the personal/dev repo — images land under <artifactory-user>/…. Product images live in :17099 and :17003; never push there.

3.2 KiB Raw Blame History