feat: add multi-stage Dockerfile for building and running app#195
feat: add multi-stage Dockerfile for building and running app#195nanotaboada merged 2 commits intomasterfrom
Conversation
WalkthroughThis update introduces containerization support for a Java Spring Boot application. It adds a multi-stage Dockerfile, a Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant GitHub Actions
participant Docker Daemon
participant GitHub Container Registry
Developer->>GitHub Actions: Push to master branch
GitHub Actions->>GitHub Actions: Run coverage job
GitHub Actions->>GitHub Actions: Run container job (after coverage)
GitHub Actions->>Docker Daemon: Build Docker image (multi-stage)
Docker Daemon->>GitHub Actions: Return built image
GitHub Actions->>GitHub Container Registry: Push Docker image (latest, sha-tagged)
sequenceDiagram
participant User
participant Docker Compose
participant Container (Spring App)
participant Healthcheck Script
User->>Docker Compose: docker compose up
Docker Compose->>Container (Spring App): Start container
Container (Spring App)->>Healthcheck Script: Run healthcheck.sh periodically
Healthcheck Script->>Container (Spring App): HTTP GET /actuator/health
Container (Spring App)->>Healthcheck Script: Responds to health check
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferences |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #195 +/- ##
===========================================
Coverage 100.00% 100.00%
Complexity 20 20
===========================================
Files 2 2
Lines 49 49
Branches 4 4
===========================================
Hits 49 49 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (9)
.dockerignore (1)
1-13: Enhancement: ignore common OS and IDE files.
To further slim down the build context, consider adding patterns such as:.DS_Store *.iml *.logThis will prevent macOS or other IDE/editor artifacts from being sent to the Docker daemon.
README.md (2)
34-52: Improve and consolidate Docker Compose commands.
You can streamline the build and startup into a single detached command:docker compose up -d --buildThis reduces the number of steps and runs the container in the background.
30-52: Document Docker prerequisites.
It would be helpful to add a "Prerequisites" section noting that Docker Engine (v20.10+) and Docker Compose (v2+) must be installed before running these commands.scripts/healthcheck.sh (1)
1-2: Use a portable shebang.
For better cross‐environment compatibility, consider using:#!/usr/bin/env shinstead of hardcoding
/bin/sh.compose.yaml (1)
1-16: Optional: specify Compose file version.
Adding a top‐level field like:version: "3.9"can clarify compatibility requirements for different Docker Compose releases.
.github/workflows/maven.yml (1)
69-103: Optional: add build cache settings.
To accelerate Docker builds, consider addingcache-fromandcache-toarguments. For example:with: context: . + cache-from: type=registry,ref=ghcr.io/${{ github.repository }}:cache + cache-to: type=inline push: true platforms: linux/amd64 provenance: false tags: | ghcr.io/${{ github.repository }}:latest ghcr.io/${{ github.repository }}:sha-${{ github.sha }}This can significantly reduce build times on subsequent runs.
Dockerfile (3)
24-26: Reduce image layers by combining package installs and user setup.
Merging APK commands and user creation into a singleRUNreduces layers and total image size.-RUN apk add --no-cache curl +RUN apk add --no-cache curl \ + && addgroup -S spring \ + && adduser -S -G spring springThen remove the separate
RUN addgroup...block at lines 46–47.Also applies to: 46-49
28-31: Enhance image metadata with version label.
Addingorg.opencontainers.image.versionaids in identifying the application version running inside the container.Add:
LABEL org.opencontainers.image.version="1.0.0"
33-34: Clarify or remove Sonar rule reference.
The inlineRSPEC-6504comment could be removed or expanded to explain why it’s relevant for this Dockerfile.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.dockerignore(1 hunks).github/workflows/maven.yml(1 hunks)Dockerfile(1 hunks)README.md(2 hunks)compose.yaml(1 hunks)scripts/healthcheck.sh(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (9)
.dockerignore (1)
1-13: .dockerignore entries optimize the build context.
The file effectively excludes project metadata, IDE folders, and build artifacts (e.g.,target), which will significantly reduce the Docker build context size.README.md (1)
30-33: New Container section is clear.
The "## Container" and "### Docker Compose" headings logically group the container usage instructions, making it easy for users to find.compose.yaml (1)
1-16: Compose service configuration is sound.
The service correctly builds from theDockerfile, maps ports, sets environment variables, and applies a restart policy..github/workflows/maven.yml (1)
69-103: Container job is configured properly.
The newcontainerjob runs only on pushes tomaster, logs in to GHCR, and uses Buildx to tag and push bothlatestand SHA‐specific images.Dockerfile (5)
5-5: Verify the availability of the base builder image.
Ensuremaven:3.9-eclipse-temurin-21-alpineis published on Docker Hub to avoid build failures due to missing tags.
36-37: Ensure deterministic JAR selection.
Using a wildcard (*.jar) may accidentally match multiple artifacts. Locking the filename prevents ambiguity.Could you confirm the produced JAR name or adjust to:
COPY --from=builder /app/target/myapp.jar ./app.jar
39-41: Approve copying documentation with read-only permissions.
Locking downREADME.mdand assets with--chmodis a good practice to prevent accidental modification at runtime.
43-44: Verify healthcheck script integrity and permissions.
Confirmscripts/healthcheck.shhas a proper shebang (#!/usr/bin/env sh) and exits non-zero on failure for Docker to mark unhealthy.
51-58: Usage of explicit exec form is correct.
JSON-formEXPOSE,HEALTHCHECK, andENTRYPOINTensure proper signal handling and metadata exposure.
5971835 to
b7b6402
Compare
|
Code Climate has analyzed commit 4c046fb and detected 1 issue on this pull request. Here's the issue category breakdown:
View more on Code Climate. |
|



This change is
Summary by CodeRabbit
.dockerignorefile to optimize Docker builds.