ci: add standalone Dockerfile validation workflow#5558
ci: add standalone Dockerfile validation workflow#5558nobodyiam merged 5 commits intoapolloconfig:masterfrom
Conversation
📝 WalkthroughWalkthroughAdds a new GitHub Actions "Docker Validation" workflow that builds and health-checks Docker images for three services when their Dockerfiles change; upgrades the three service Dockerfiles to Eclipse Temurin Java 17 and standardizes noninteractive apt installs and timezone setup. Changes
Sequence DiagramsequenceDiagram
participant GH as GitHub Actions
participant CI as CI Job
participant Docker as Docker Engine
participant Img as Image
participant Cont as Container
participant Health as /health endpoint
GH->>CI: Trigger (PR or manual)
CI->>CI: Checkout, setup JDK 17, cache Maven, build project, resolve version
CI->>Docker: Build service image (tagged with version)
Docker->>Img: Assemble image
CI->>Docker: Run container (service env/ports)
Cont->>Health: Start service, expose /health
CI->>Health: Poll /health until healthy or timeout
CI->>Cont: Exec startup script and `java -version` inside container
CI->>Cont: Collect logs, stop and remove container
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (6)
apollo-configservice/src/main/docker/Dockerfile (2)
38-40: SetDEBIAN_FRONTEND=noninteractiveto avoidtzdatadebconf hang.
tzdatatriggers adebconfinteractive prompt for geographic area/timezone in Ubuntu-based Docker builds. The-yflag only suppresses apt's own confirmations, not the post-install debconf questionnaire. WithoutDEBIAN_FRONTEND=noninteractive,docker buildcan hang indefinitely in CI waiting for input.🔧 Proposed fix
-RUN apt-get update \ - && apt-get install -y --no-install-recommends procps curl bash tzdata \ - && rm -rf /var/lib/apt/lists/* \ +RUN DEBIAN_FRONTEND=noninteractive apt-get update \ + && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends procps curl bash tzdata \ + && rm -rf /var/lib/apt/lists/* \Prefer scoping
DEBIAN_FRONTENDto theRUNlayer rather than a top-levelENVto avoid leaking it into runtime.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apollo-configservice/src/main/docker/Dockerfile` around lines 38 - 40, The Dockerfile's apt installs can hang on tzdata debconf prompts; scope DEBIAN_FRONTEND=noninteractive to the relevant RUN lines that perform apt-get install (the RUN commands installing packages) so the noninteractive mode only applies during image build and not at runtime; update the RUN lines that call apt-get install to prefix them with DEBIAN_FRONTEND=noninteractive and ensure apt-get update && apt-get install -y ... && rm -rf /var/lib/apt/lists/* remains in the same RUN so the variable is applied for the entire install step.
32-32: Pin the Docker image tag for reproducible builds.The base image tag
eclipse-temurin:17-jre-jammyis floating and will resolve to different JRE patch versions on fresh CI runs. Currently resolves to17.0.18_8-jre-jammy, but future pulls will pick up the latest patch as Temurin releases quarterly updates. For reproducible builds, pin to the specific version:🔧 Proposed fix
-FROM eclipse-temurin:17-jre-jammy +FROM eclipse-temurin:17.0.18_8-jre-jammy🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apollo-configservice/src/main/docker/Dockerfile` at line 32, The Dockerfile's FROM line uses a floating tag "eclipse-temurin:17-jre-jammy" which should be pinned for reproducible builds; update the FROM instruction (referenced as the image string "eclipse-temurin:17-jre-jammy") to a specific patch-version tag (e.g., the current resolved "eclipse-temurin:17.0.18_8-jre-jammy" or whatever exact patch you want to lock to) so CI and local builds always use the same JRE patch.apollo-portal/src/main/docker/Dockerfile (1)
32-32: Consider pinning the base image tag to a specific patch version for reproducible builds.
eclipse-temurin:17-jre-jammyis a floating tag—it receives JDK patch updates on a quarterly release cadence, which means this tag will resolve to different patch versions over time. The currently pinned equivalent is17.0.18_8-jre-jammy.📌 Suggested pinned tag
-FROM eclipse-temurin:17-jre-jammy +FROM eclipse-temurin:17.0.18_8-jre-jammyThe Java 8 → 17 runtime upgrade is compatible with the application: the code compiles to Java 8 bytecode (forward compatible with Java 17), Spring Boot 2.7.11 fully supports Java 17, and dependencies (Guava 32.0.0, Javassist, JAXB) are all compatible. The startup script also already has version detection that applies appropriate JVM flags for Java 17 (modern
-XlogGC syntax instead of deprecated CMS flags).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apollo-portal/src/main/docker/Dockerfile` at line 32, Update the Dockerfile's base image reference to a fixed Java 17 patch tag instead of the floating one: replace the FROM image string "eclipse-temurin:17-jre-jammy" with the pinned patch-level tag (e.g., "eclipse-temurin:17.0.18_8-jre-jammy") so builds are reproducible; ensure the change is applied where the Dockerfile's FROM line defines the base image and update any related build/test documentation if it references the previous floating tag.apollo-adminservice/src/main/docker/Dockerfile (1)
32-32: Consider pinning the base image to a digest for reproducible builds.Temurin updates Dockerfiles on a quarterly PSU cadence, meaning the
17-jre-jammyfloating tag can silently pull in a different layer across environments. Pinning by digest ensures build-over-build reproducibility.♻️ Proposed refactor
-FROM eclipse-temurin:17-jre-jammy +FROM eclipse-temurin:17-jre-jammy@sha256:<digest>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apollo-adminservice/src/main/docker/Dockerfile` at line 32, Replace the floating Temurin tag with a digest-pinned image to ensure reproducible builds: locate the Dockerfile line containing "FROM eclipse-temurin:17-jre-jammy" and update it to use the corresponding content-addressable digest (e.g., "FROM eclipse-temurin@sha256:...") by looking up the correct sha256 for the desired 17-jre-jammy artifact in the registry; commit the updated Dockerfile so future builds always pull the exact same image..github/workflows/docker-validation.yml (2)
144-158: Consider increasing the health-check timeout beyond 120 s.The loop polls
/healthfor at most 120 iterations (≈ 2 minutes). On shared GitHub-hosted runners, a cold Spring Boot start against an H2 in-memory DB can take longer under high runner load, making this smoke test intermittently flaky. Consider raising the limit to180or extracting it as a named local variable so it is easy to tune without hunting through the loop body.♻️ Proposed change
+ local max_attempts=180 local healthy=0 ... - for i in $(seq 1 120); do + for i in $(seq 1 $max_attempts); do🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/docker-validation.yml around lines 144 - 158, The health-check loop currently uses a hard-coded 120-iteration limit which can make the smoke test flaky; update the loop to replace the magic value 120 with a named variable (e.g., MAX_HEALTH_CHECK_ITERATIONS) and set it to 180 (or another tunable value), then use that variable in the polling loop and any related timeout calculations so the timeout is easy to tune without hunting through the loop body.
169-170: Remove redundanttest -xfrom thejava -versioncheck.The
test -x '${startup_script}'at Line 170 duplicates the same check already performed inside the firstdocker run(Line 142). If the startup script were not executable, the container would have exited before the health check succeeded and the function would have already returned 1. The second occurrence is dead code and can be dropped.♻️ Proposed change
docker run --rm --entrypoint /bin/bash "$image_tag" \ - -c "set -euo pipefail; test -x '${startup_script}'; java -version" + -c "java -version"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/docker-validation.yml around lines 169 - 170, Remove the redundant "test -x '${startup_script}'" from the health-check that runs the "java -version" validation: locate the health check command that includes "java -version" and references the startup_script variable and simply drop the duplicate "test -x '${startup_script}'" condition (leaving the existing executable check in the earlier docker run intact), so the health-check no longer repeats the same executability test.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/docker-validation.yml:
- Around line 76-78: Update the GitHub Actions step using actions/setup-java to
a current major (e.g., actions/setup-java@v4) and set distribution: "temurin"
and java-version: "17" in that workflow, and also change the Maven build target
by updating the pom.xml property <java.version> from 1.8 to 17 so the build JDK
matches the Docker runtime image (eclipse-temurin:17-jre-jammy); locate the
workflow step referencing actions/setup-java and the pom.xml entry for
java.version to make these coordinated changes.
In `@apollo-adminservice/src/main/docker/Dockerfile`:
- Around line 38-42: Set DEBIAN_FRONTEND=noninteractive for the RUN that
installs tzdata to avoid interactive prompts and make builds reproducible:
update the RUN that currently installs tzdata (the apt-get install line in the
Dockerfile) to export or prefix DEBIAN_FRONTEND=noninteractive. Also remove
unnecessary runtime packages—specifically drop curl (and optionally bash if you
confirm startup.sh does not require it) from the apt-get install list so the
production image does not carry an unnecessary network tool; verify startup.sh
or any runtime scripts do not depend on curl before removing it.
---
Nitpick comments:
In @.github/workflows/docker-validation.yml:
- Around line 144-158: The health-check loop currently uses a hard-coded
120-iteration limit which can make the smoke test flaky; update the loop to
replace the magic value 120 with a named variable (e.g.,
MAX_HEALTH_CHECK_ITERATIONS) and set it to 180 (or another tunable value), then
use that variable in the polling loop and any related timeout calculations so
the timeout is easy to tune without hunting through the loop body.
- Around line 169-170: Remove the redundant "test -x '${startup_script}'" from
the health-check that runs the "java -version" validation: locate the health
check command that includes "java -version" and references the startup_script
variable and simply drop the duplicate "test -x '${startup_script}'" condition
(leaving the existing executable check in the earlier docker run intact), so the
health-check no longer repeats the same executability test.
In `@apollo-adminservice/src/main/docker/Dockerfile`:
- Line 32: Replace the floating Temurin tag with a digest-pinned image to ensure
reproducible builds: locate the Dockerfile line containing "FROM
eclipse-temurin:17-jre-jammy" and update it to use the corresponding
content-addressable digest (e.g., "FROM eclipse-temurin@sha256:...") by looking
up the correct sha256 for the desired 17-jre-jammy artifact in the registry;
commit the updated Dockerfile so future builds always pull the exact same image.
In `@apollo-configservice/src/main/docker/Dockerfile`:
- Around line 38-40: The Dockerfile's apt installs can hang on tzdata debconf
prompts; scope DEBIAN_FRONTEND=noninteractive to the relevant RUN lines that
perform apt-get install (the RUN commands installing packages) so the
noninteractive mode only applies during image build and not at runtime; update
the RUN lines that call apt-get install to prefix them with
DEBIAN_FRONTEND=noninteractive and ensure apt-get update && apt-get install -y
... && rm -rf /var/lib/apt/lists/* remains in the same RUN so the variable is
applied for the entire install step.
- Line 32: The Dockerfile's FROM line uses a floating tag
"eclipse-temurin:17-jre-jammy" which should be pinned for reproducible builds;
update the FROM instruction (referenced as the image string
"eclipse-temurin:17-jre-jammy") to a specific patch-version tag (e.g., the
current resolved "eclipse-temurin:17.0.18_8-jre-jammy" or whatever exact patch
you want to lock to) so CI and local builds always use the same JRE patch.
In `@apollo-portal/src/main/docker/Dockerfile`:
- Line 32: Update the Dockerfile's base image reference to a fixed Java 17 patch
tag instead of the floating one: replace the FROM image string
"eclipse-temurin:17-jre-jammy" with the pinned patch-level tag (e.g.,
"eclipse-temurin:17.0.18_8-jre-jammy") so builds are reproducible; ensure the
change is applied where the Dockerfile's FROM line defines the base image and
update any related build/test documentation if it references the previous
floating tag.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/docker-validation.yml (1)
56-57: Fail-fast behavior: subsequent services are skipped if an earlier validation fails.With
set -euo pipefail, ifapollo-configservicevalidation fails,adminserviceandportalare never tested. This is reasonable for a smoke check, but if you'd prefer to validate all three and report all failures, you could collect exit codes and defer the failure. Just noting the trade-off — the current approach is fine for a CI gate.Also applies to: 131-159
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/docker-validation.yml around lines 56 - 57, Current use of "set -euo pipefail" makes the script fail fast so if apollo-configservice validation fails the subsequent adminservice and portal validations are skipped; to validate all three, run each validation command for apollo-configservice, adminservice, and portal in sequence but disable immediate exit for that block (e.g., temporarily unset -e or append "|| true" per command), capture each command's exit code into distinct variables, and after running all validations aggregate those codes and exit non-zero if any failed so the job reports all failures instead of stopping on the first error.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apollo-configservice/src/main/docker/Dockerfile`:
- Around line 38-42: The apt install line in the RUN instruction that installs
"procps curl bash tzdata" should be trimmed to remove "bash" and "curl" — update
the RUN apt-get install invocation so it only installs "procps" and "tzdata"
(and keeps the existing flags and cleanup), because the base image already
provides bash and the Dockerized startup path (APOLLO_RUN_MODE="Docker") never
executes the curl-dependent code in startup.sh; ensure the rest of the RUN chain
(DEBIAN_FRONTEND=noninteractive, --no-install-recommends, rm -rf
/var/lib/apt/lists/*, timezone symlink and /etc/timezone echo) remains
unchanged.
---
Duplicate comments:
In `@apollo-adminservice/src/main/docker/Dockerfile`:
- Around line 38-42: The RUN instruction installs curl and bash into the runtime
image unnecessarily; remove curl and bash from the runtime-stage RUN (or move
their installation into the build stage) so the final image only contains
required packages (e.g., leave procps and tzdata if needed). Locate the RUN line
installing "procps curl bash tzdata" and either delete "curl" and "bash" from
that package list or ensure those packages are only installed in an earlier
build stage used for tooling; also verify any scripts referencing "bash" or
"curl" are adjusted to use /bin/sh or a runtime-safe downloader (or copied from
the build stage) so the final image runs without curl/bash.
---
Nitpick comments:
In @.github/workflows/docker-validation.yml:
- Around line 56-57: Current use of "set -euo pipefail" makes the script fail
fast so if apollo-configservice validation fails the subsequent adminservice and
portal validations are skipped; to validate all three, run each validation
command for apollo-configservice, adminservice, and portal in sequence but
disable immediate exit for that block (e.g., temporarily unset -e or append "||
true" per command), capture each command's exit code into distinct variables,
and after running all validations aggregate those codes and exit non-zero if any
failed so the job reports all failures instead of stopping on the first error.
| RUN DEBIAN_FRONTEND=noninteractive apt-get update \ | ||
| && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends procps curl bash tzdata \ | ||
| && rm -rf /var/lib/apt/lists/* \ | ||
| && ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ | ||
| && echo "Asia/Shanghai" > /etc/timezone |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd apollo-configservice && cat -n src/main/docker/Dockerfile | head -50Repository: apolloconfig/apollo
Length of output: 2455
🏁 Script executed:
fd -g 'startup.sh' --type fRepository: apolloconfig/apollo
Length of output: 201
🏁 Script executed:
# Search for all startup scripts in the repository to understand the startup context
find . -type f -name '*startup*'Repository: apolloconfig/apollo
Length of output: 207
🏁 Script executed:
cat -n apollo-configservice/src/main/scripts/startup.shRepository: apolloconfig/apollo
Length of output: 9498
🏁 Script executed:
# Also check the apollo-adminservice startup.sh to understand the previous context
cat -n apollo-adminservice/src/main/scripts/startup.shRepository: apolloconfig/apollo
Length of output: 9497
Trim bash and curl from the install list — both are redundant in this Docker setup.
bash is already included in the eclipse-temurin:17.0.18_8-jre-jammy base image (Ubuntu 22.04 ships it by default).
curl is called in startup.sh only within the non-Docker code paths (lines 76, 84), which are skipped entirely when APOLLO_RUN_MODE="Docker" is set. Since the Dockerfile explicitly sets this environment variable, the curl-dependent port-check logic never executes. Removing it reduces the attack surface.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apollo-configservice/src/main/docker/Dockerfile` around lines 38 - 42, The
apt install line in the RUN instruction that installs "procps curl bash tzdata"
should be trimmed to remove "bash" and "curl" — update the RUN apt-get install
invocation so it only installs "procps" and "tzdata" (and keeps the existing
flags and cleanup), because the base image already provides bash and the
Dockerized startup path (APOLLO_RUN_MODE="Docker") never executes the
curl-dependent code in startup.sh; ensure the rest of the RUN chain
(DEBIAN_FRONTEND=noninteractive, --no-install-recommends, rm -rf
/var/lib/apt/lists/*, timezone symlink and /etc/timezone echo) remains
unchanged.
There was a problem hiding this comment.
Thanks for the follow-up. This is a valid optimization, but I am not removing curl/bash in this PR yet: we keep all three service images consistent and prioritize runtime compatibility first (startup.sh still uses curl in non-Docker path and depends on bash semantics).\n\nThis PR is focused on Docker Validation workflow rollout and CI stability. I will handle image footprint hardening in a separate PR with dedicated validation.
There was a problem hiding this comment.
@nobodyiam, thank you for the thoughtful response! Your approach makes perfect sense — keeping the PR focused on the Docker validation workflow and maintaining consistency across the service images is a solid strategy. Image optimization is indeed better suited for a dedicated PR where you can validate the changes comprehensively.
Would you like me to create a GitHub issue to track the future work on removing unnecessary dependencies (curl/bash) from the Docker images? That way it won't get lost and can be picked up when you're ready to tackle the image slimming effort.
There was a problem hiding this comment.
Pull request overview
This PR introduces a dedicated CI workflow to validate Dockerfiles independently from the main Java build workflow, and updates Apollo service runtime Docker images to use a Java 17 base image.
Changes:
- Added a new GitHub Actions workflow (
docker-validation.yml) to build and smoke-test containers for changed Dockerfiles (or all via manual dispatch). - Updated runtime base images in service Dockerfiles from
openjdk:8-jre-slimtoeclipse-temurin:17-jre-jammy, and simplified apt setup. - Recorded the CI enhancement in
CHANGES.md.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/docker-validation.yml |
New workflow to detect changed Dockerfiles and run build + container health smoke checks. |
apollo-portal/src/main/docker/Dockerfile |
Switch portal runtime image to Temurin JRE 17 on Jammy; simplify apt steps. |
apollo-configservice/src/main/docker/Dockerfile |
Switch configservice runtime image to Temurin JRE 17 on Jammy; simplify apt steps. |
apollo-adminservice/src/main/docker/Dockerfile |
Switch adminservice runtime image to Temurin JRE 17 on Jammy; simplify apt steps. |
CHANGES.md |
Adds an entry documenting the new standalone Docker validation workflow. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| for i in $(seq 1 "$max_health_check_attempts"); do | ||
| if curl --silent --fail "http://127.0.0.1:${host_port}/health" | grep -q "UP"; then | ||
| healthy=1 |
There was a problem hiding this comment.
actions/setup-java@v1 is end-of-life (Node 12-based) and may break as GitHub Actions deprecates older runtimes. Please switch this workflow to actions/setup-java@v4 (with an explicit distribution, e.g. temurin) to match the newer workflows in this repo and improve long-term reliability.
There was a problem hiding this comment.
Thanks for the review. This appears to be based on stale context: in the current PR head, .github/workflows/docker-validation.yml already uses actions/setup-java@v4 with distribution: temurin and java-version: 17.
There was a problem hiding this comment.
🧹 Nitpick comments (3)
apollo-configservice/src/main/docker/Dockerfile (2)
32-32: Consider pinning the runtime base image to a specific patch tag for reproducible builds.
eclipse-temurin:17-jre-jammyis a mutable floating tag; successive CI builds can silently pull a different JRE patch, making the build non-reproducible and potentially masking regressions. Temurin releases Patch Set Updates on a quarterly cadence, so the resolved image can change without any change to this Dockerfile.The current latest patch tag for Java 17 is
17.0.18_8, so pinning would look like:📌 Proposed pin to current patch tag
-FROM eclipse-temurin:17-jre-jammy +FROM eclipse-temurin:17.0.18_8-jre-jammy🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apollo-configservice/src/main/docker/Dockerfile` at line 32, The FROM line uses a floating tag "eclipse-temurin:17-jre-jammy"; replace it with a specific patch-pinned image such as "eclipse-temurin:17.0.18_8-jre-jammy" in the Dockerfile's FROM instruction to ensure reproducible builds (update the pinned patch tag as needed in the future).
32-32: Consider pinning the runtime base image to a specific patch tag for reproducible builds.
eclipse-temurin:17-jre-jammyis a mutable floating tag; successive builds can silently pull a different JRE patch version. Specific patch tags likeeclipse-temurin:17.0.17_10-jre-jammyare available and recommended for full build reproducibility, making it easier to bisect regressions and ensure consistency across environments.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apollo-configservice/src/main/docker/Dockerfile` at line 32, The Dockerfile's base image uses a floating tag (FROM eclipse-temurin:17-jre-jammy) which can change across builds; update the FROM instruction in the Dockerfile to a specific patch-pinned tag (for example, eclipse-temurin:17.0.17_10-jre-jammy) so the runtime is fixed and builds are reproducible — replace the existing FROM line with the chosen explicit patch tag.apollo-portal/src/main/docker/Dockerfile (1)
38-39: RedundantDEBIAN_FRONTEND=noninteractiveprefix.Both
apt-get updateandapt-get installare chained in a single RUN shell invocation, so the variable set forupdateis already in scope for the subsequent&&command. The second inline assignment is a no-op.♻️ Proposed simplification
-RUN DEBIAN_FRONTEND=noninteractive apt-get update \ - && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends procps curl bash tzdata \ +RUN DEBIAN_FRONTEND=noninteractive apt-get update \ + && apt-get install -y --no-install-recommends procps curl bash tzdata \🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apollo-portal/src/main/docker/Dockerfile` around lines 38 - 39, In the Dockerfile RUN line that currently prefixes both commands with DEBIAN_FRONTEND=noninteractive (e.g., "DEBIAN_FRONTEND=noninteractive apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install ..."), remove the redundant second prefix so only the first assignment is used (e.g., "DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install ..."); this keeps the noninteractive setting in scope for the chained command while simplifying the command string.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@apollo-configservice/src/main/docker/Dockerfile`:
- Line 32: The FROM line uses a floating tag "eclipse-temurin:17-jre-jammy";
replace it with a specific patch-pinned image such as
"eclipse-temurin:17.0.18_8-jre-jammy" in the Dockerfile's FROM instruction to
ensure reproducible builds (update the pinned patch tag as needed in the
future).
- Line 32: The Dockerfile's base image uses a floating tag (FROM
eclipse-temurin:17-jre-jammy) which can change across builds; update the FROM
instruction in the Dockerfile to a specific patch-pinned tag (for example,
eclipse-temurin:17.0.17_10-jre-jammy) so the runtime is fixed and builds are
reproducible — replace the existing FROM line with the chosen explicit patch
tag.
In `@apollo-portal/src/main/docker/Dockerfile`:
- Around line 38-39: In the Dockerfile RUN line that currently prefixes both
commands with DEBIAN_FRONTEND=noninteractive (e.g.,
"DEBIAN_FRONTEND=noninteractive apt-get update && DEBIAN_FRONTEND=noninteractive
apt-get install ..."), remove the redundant second prefix so only the first
assignment is used (e.g., "DEBIAN_FRONTEND=noninteractive apt-get update &&
apt-get install ..."); this keeps the noninteractive setting in scope for the
chained command while simplifying the command string.
What's the purpose of this PR
This PR adds a dedicated Docker validation workflow so Dockerfile verification is decoupled from the main Java build workflow.
It also updates Apollo service Docker runtime images to a valid Java 17 base image and runs smoke checks with H2.
Which issue(s) this PR fixes:
Fixes #
Brief changelog
.github/workflows/docker-validation.yml./scripts/build.shdocker build+ container startup smoke checks (/health) with H2h2,authforapollo-portal.github/workflows/build.ymlfocused on Java build/test matrix onlyeclipse-temurin:17-jre-jammyFollow this checklist to help us incorporate your contribution quickly and easily:
mvn clean testto make sure this pull request doesn't break anything.mvn spotless:applyto format your code.CHANGESlog.Validation
bash -n) for validation script blockapollo-configservice,apollo-adminservice)Summary by CodeRabbit
New Features
Chores
Documentation