Consolidate tool Dockerfiles into a single multi-stage Dockerfile by Copilot · Pull Request #111 · mdenet/platformtools

Copilot · 2026-03-24T20:25:46Z

Create a single root-level Dockerfile with:
- One Maven build stage (mavenbuilder) that builds ALL tools with -Pall
- Separate npm/static build stages for each tool frontend (emf, emfatic, ocl, conversion, xtext)
- Separate final service stages for each tool (emf, emfatic, ocl, conversion, xtext)
Each tool service stage copies only the Maven module folders needed for that tool (matching the original per-tool Dockerfile Maven profiles)
Verify the new Dockerfile has correct COPY paths (build context must be the repo root)
Run code review and CodeQL security check

Original prompt

This section details on the original issue you should resolve

<issue_title>Improve tool Docker file performance</issue_title>
<issue_description>The docker files for the various tools (/static.xxx/Dockerfile) re-run Maven repeatedly. The way this is currently written, docker has no way to identify that parts of this build are redundant.

Instead, we should have just one staged-build Dockerfile for all tool services. This would start with a stage that builds all tools in one Maven call and then we would have separate stages for building each tool, copying the required information as and when. In the main docker-compose file, we then call the appropriate stage in this central Dockerfile instead of using a separate Dockerfile for each tool.

This way, Maven has to run once and the results can then be cached by Docker across all tools. </issue_description>

<agent_instructions>Make a first refactoring of all the relevant Dockerfiles into one central Dockerfile. Ignore the comment about the central docker-compose file, which is in a separate repository and needs a separate PR there.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Fixes Improve tool Docker file performance #110

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Co-authored-by: szschaler <7057319+szschaler@users.noreply.github.com> Agent-Logs-Url: https://github.com/mdenet/platformtools/sessions/b6ab5268-aa41-46be-9015-ddb9c14527a4

szschaler · 2026-03-24T21:59:49Z

Dockerfile

+
+# Copy built tool and sources
+COPY --from=mavenbuilder /root/.m2 /root/.m2
+COPY --from=mavenbuilder /usr/src/toolfunctions /toolservice


This line, and the corresponding ones in the other service build stages, needs to only copy the folders actually needed by each tool. Check out the maven build in the respective bespoke Dockerfiles to work out which folders these are.

Done in f1b6062. Each tool service stage now copies only its required module folders, matching the Maven profiles from the original per-tool Dockerfiles:

emf: core, emf, emffunction

emfatic: core, emf, emfatic, emfaticfunction

ocl: core, eclipseocl, eclipseoclfunction

conversion: core, emf, epsilon, epsilonfunction

xtext: core, emf, xtext, xtextfunction

Co-authored-by: szschaler <7057319+szschaler@users.noreply.github.com> Agent-Logs-Url: https://github.com/mdenet/platformtools/sessions/e691f0eb-fb24-4c42-8fd9-8ba24d1e203f

Copilot

Pull request overview

This PR introduces a single root-level multi-stage Dockerfile that centralizes the Maven build for all tool services and then produces separate final images per tool by targeting different stages.

Changes:

Adds a root Dockerfile with a shared mavenbuilder stage that builds all tool modules with -Pall.
Adds per-tool frontend build stages (EMF, Emfatic, OCL, Conversion, Xtext) and per-tool final service stages.
Updates service stages to copy only the Maven module folders needed for each tool (mirroring the original per-tool profile module sets).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-03-24T22:09:47Z

Dockerfile

+FROM node:19-bullseye AS staticbuild-emf
+
+WORKDIR /usr/src/mdenet-tool
+
+COPY static.emf/package*.json ./
+COPY static.emf .
+
+RUN npm install; npm run build; chmod -R 755 dist/
+
+
+# ---------------------------------------------------------------------------
+# Stage 2b – Static frontend build for Emfatic
+# ---------------------------------------------------------------------------
+FROM node:19-bullseye AS staticbuild-emfatic
+
+WORKDIR /usr/src/mdenet-tool
+
+COPY static.emfatic/package*.json ./
+COPY static.emfatic .
+
+RUN npm install; npm run build; chmod -R 755 dist/


This stage uses node:19-bullseye. Node 19 is long EOL, so continuing to build on it increases security risk and may break future dependency installs. Please switch these frontend build stages to a supported LTS base image (and keep it consistent with the Node version used in the Xtext service stage).

Copilot · 2026-03-24T22:09:47Z

Dockerfile

+COPY static.conversion/package*.json ./
+COPY static.conversion .
+
+RUN npm install; npm run build; chmod -R 755 dist/


Same issue here: npm install; npm run build; ... should use && to avoid masking failures, and npm ci is preferred for reproducible builds when package-lock.json exists.

Copilot · 2026-03-24T22:09:47Z

Dockerfile

+COPY xtext/static.xtext/package*.json ./
+COPY xtext/static.xtext .
+
+RUN npm install; npm run build; chmod -R 755 dist/


Same issue here: npm install; npm run build; ... should use && to ensure failures fail the build, and prefer npm ci for lockfile installs.

Copilot · 2026-03-24T22:09:47Z

Dockerfile

+    && if [ "$ARCH" = "arm64" ] || [ "$ARCH" = "aarch64" ]; then NODE_ARCH="linux-arm64"; else NODE_ARCH="linux-x64"; fi \
+    && NODE_RELEASE="node-v${NODE_VERSION}-${NODE_ARCH}" \
+    && echo "Installing ${NODE_RELEASE}" \
+    && curl --output ${NODE_RELEASE}.tar.xz https://nodejs.org/download/release/v${NODE_VERSION}/${NODE_RELEASE}.tar.xz \


The Xtext service installs Node by downloading a tarball via curl without any integrity verification (checksum/signature). This is a supply-chain risk; prefer installing Node from a trusted distribution mechanism (OS packages/Nodesource) or verify the download using published SHASUMS before extracting.

Suggested change

&& curl --output ${NODE_RELEASE}.tar.xz https://nodejs.org/download/release/v${NODE_VERSION}/${NODE_RELEASE}.tar.xz \

&& curl -fsSL -o ${NODE_RELEASE}.tar.xz https://nodejs.org/download/release/v${NODE_VERSION}/${NODE_RELEASE}.tar.xz \

&& curl -fsSL -o SHASUMS256.txt https://nodejs.org/download/release/v${NODE_VERSION}/SHASUMS256.txt \

&& grep " ${NODE_RELEASE}.tar.xz\$" SHASUMS256.txt > SHASUMS256.txt.node \

&& sha256sum -c SHASUMS256.txt.node \

Copilot · 2026-03-24T22:09:48Z

Dockerfile

+# The release of node to install
+ENV NODE_VERSION=19.9.0


NODE_VERSION=19.9.0 is an EOL Node release. Please switch to a currently supported LTS version to reduce CVE exposure and keep npm dependency installs working over time.

Copilot · 2026-03-24T22:09:48Z

Dockerfile

+COPY static.emfatic/package*.json ./
+COPY static.emfatic .
+
+RUN npm install; npm run build; chmod -R 755 dist/


Same as the EMF static build: npm install; npm run build; ... should be changed to use && (to avoid masking failures) and preferably npm ci for reproducible installs when package-lock.json is present.

Copilot · 2026-03-24T22:09:48Z

Dockerfile

+COPY static.ocl/package*.json ./
+COPY static.ocl .
+
+RUN npm install; npm run build; chmod -R 755 dist/


Same issue here: using ; between npm commands can allow the Docker build to succeed even if npm install/npm run build fails (depending on the last command). Use && chaining and consider npm ci for lockfile-based installs.

Copilot · 2026-03-24T22:09:49Z

Dockerfile

+RUN apt-get update && apt-get install -y --no-install-recommends unzip zip xz-utils maven cron psmisc
+


apt-get update && apt-get install ... in this stage doesn't clean /var/lib/apt/lists/*, which leaves package index files in the image and increases size. Consider adding the standard cleanup (and similarly remove any temporary artifacts created during Node installation) to keep the final image leaner.

Copilot · 2026-03-24T22:09:49Z

Dockerfile

+COPY services /usr/src/toolfunctions
+
+WORKDIR /usr/src/toolfunctions
+


The Maven build stage copies the entire services/ tree before running mvn, which means any change anywhere under services/ will invalidate the Docker cache for dependency download/build. To better leverage caching, copy services/pom.xml (and any other Maven metadata) first and run a dependency prefetch (or mvn -Pall -DskipTests ... as appropriate), then copy the rest of the sources and run the full build.

Suggested change

COPY services /usr/src/toolfunctions

WORKDIR /usr/src/toolfunctions

WORKDIR /usr/src/toolfunctions

# Copy Maven metadata first to leverage Docker layer caching for dependencies

COPY services/pom.xml /usr/src/toolfunctions/pom.xml

# Prefetch Maven dependencies without running tests or doing a full build

RUN mvn -Pall -DskipTests dependency:go-offline

# Now copy the full source tree and perform the actual build

COPY services /usr/src/toolfunctions

Copilot · 2026-03-24T22:09:49Z

Dockerfile

+COPY static.emf/package*.json ./
+COPY static.emf .
+
+RUN npm install; npm run build; chmod -R 755 dist/


Dependency caching for this frontend stage is reduced because npm install runs after copying the full source tree. Consider copying only package*.json, running npm ci, then copying the rest of the sources and running the build (also use && instead of ; to avoid masking failures).

Initial plan

830d111

Copilot AI assigned Copilot and szschaler Mar 24, 2026

Copilot started work on behalf of szschaler March 24, 2026 20:25 View session

Add central multi-stage Dockerfile for all tool services

975a61c

Co-authored-by: szschaler <7057319+szschaler@users.noreply.github.com> Agent-Logs-Url: https://github.com/mdenet/platformtools/sessions/b6ab5268-aa41-46be-9015-ddb9c14527a4

Copilot AI changed the title ~~[WIP] Refactor tool Dockerfiles into one central Dockerfile~~ Consolidate tool Dockerfiles into a single multi-stage Dockerfile Mar 24, 2026

Copilot AI requested a review from szschaler March 24, 2026 20:29

Copilot finished work on behalf of szschaler March 24, 2026 20:29

szschaler requested changes Mar 24, 2026

View reviewed changes

Copilot started work on behalf of szschaler March 24, 2026 22:00 View session

Scope Maven artifact copies to only the modules required per tool

f1b6062

Co-authored-by: szschaler <7057319+szschaler@users.noreply.github.com> Agent-Logs-Url: https://github.com/mdenet/platformtools/sessions/e691f0eb-fb24-4c42-8fd9-8ba24d1e203f

Copilot AI requested a review from szschaler March 24, 2026 22:02

Copilot finished work on behalf of szschaler March 24, 2026 22:02

szschaler requested a review from Copilot March 24, 2026 22:05

Copilot started reviewing on behalf of szschaler March 24, 2026 22:05 View session

Copilot AI reviewed Mar 24, 2026

View reviewed changes

-    && curl --output ${NODE_RELEASE}.tar.xz https://nodejs.org/download/release/v${NODE_VERSION}/${NODE_RELEASE}.tar.xz \
+    && curl -fsSL -o ${NODE_RELEASE}.tar.xz https://nodejs.org/download/release/v${NODE_VERSION}/${NODE_RELEASE}.tar.xz \
+    && curl -fsSL -o SHASUMS256.txt https://nodejs.org/download/release/v${NODE_VERSION}/SHASUMS256.txt \
+    && grep " ${NODE_RELEASE}.tar.xz\$" SHASUMS256.txt > SHASUMS256.txt.node \
+    && sha256sum -c SHASUMS256.txt.node \

		RUN apt-get update && apt-get install -y --no-install-recommends unzip zip xz-utils maven cron psmisc

		COPY services /usr/src/toolfunctions

		WORKDIR /usr/src/toolfunctions

-COPY services /usr/src/toolfunctions
-WORKDIR /usr/src/toolfunctions
+WORKDIR /usr/src/toolfunctions
+# Copy Maven metadata first to leverage Docker layer caching for dependencies
+COPY services/pom.xml /usr/src/toolfunctions/pom.xml
+# Prefetch Maven dependencies without running tests or doing a full build
+RUN mvn -Pall -DskipTests dependency:go-offline
+# Now copy the full source tree and perform the actual build
+COPY services /usr/src/toolfunctions

Conversation

Copilot AI commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Comments on the Issue (you are @copilot in this section)

Uh oh!

szschaler Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copilot AI commented Mar 24, 2026 •

edited

Loading