-
Notifications
You must be signed in to change notification settings - Fork 4
feat: version pin to latest maildev version and add workflow for publish #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughThe pull request introduces two main changes: an updated Dockerfile that upgrades the base image from Alpine 3.15 to 3.22, restructures the multi-stage build with expanded build and production stages including new workdirs, artifact copying, port exposure, and entrypoint configuration; and a new GitHub Actions workflow that automates building and pushing Docker images to a registry on release events, with support for multi-architecture builds (linux/amd64 and linux/arm64) using Docker Buildx and QEMU. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–25 minutes
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/workflows/publish.yaml (1)
19-20: Setup Docker Buildx is unused; consider usingdocker/build-push-actioninstead.The workflow sets up Docker Buildx but then uses the native
docker buildcommand directly, which doesn't leverage the buildx capabilities. This setup is unnecessary overhead.The recommended approach is to use the official
docker/build-push-actionwhich encapsulates build, tag, and push operations in a single step. This would also simplify the workflow significantly by eliminating the need for separate build and push steps.Here's a refactored version:
- - name: Set up Docker Buildx - uses: docker/setup-buildx-action@v3 - - - name: Log in to Docker Hub - uses: docker/login-action@v3 - with: - username: ${{ secrets.DOCKER_USERNAME }} - password: ${{ secrets.DOCKER_PASSWORD }} - - - name: Extract version from release tag - id: version - run: | - # Remove 'v' prefix if present (e.g., v1.0.0 -> 1.0.0) - VERSION=${GITHUB_REF#refs/tags/} - VERSION=${VERSION#v} - echo "version=$VERSION" >> $GITHUB_OUTPUT - - - name: Build Docker image - run: | - docker build \ - --tag ${{ env.IMAGE_NAME }}:${{ steps.version.outputs.version }} \ - --tag ${{ env.IMAGE_NAME }}:latest \ - . - - - name: Push Docker image - run: | - docker push ${{ env.IMAGE_NAME }}:${{ steps.version.outputs.version }} - docker push ${{ env.IMAGE_NAME }}:latest + - name: Extract version from release tag + id: version + run: | + VERSION=${GITHUB_REF#refs/tags/} + VERSION=${VERSION#v} + echo "version=$VERSION" >> $GITHUB_OUTPUT + + - name: Build and push Docker image + uses: docker/build-push-action@v5 + with: + context: . + push: true + tags: | + ${{ env.IMAGE_NAME }}:${{ steps.version.outputs.version }} + ${{ env.IMAGE_NAME }}:latest + username: ${{ secrets.DOCKER_USERNAME }} + password: ${{ secrets.DOCKER_PASSWORD }}The
docker/build-push-actionautomatically handles authentication and uses buildx under the hood for optimized builds.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/publish.yaml(1 hunks)Dockerfile(2 hunks)
🔇 Additional comments (3)
Dockerfile (3)
9-9: Multi-stage build structure and dependency management are well-executed.The Dockerfile improvements show good practices:
- Separates build tools into a dedicated build stage (lines 9, 17-21)
- Minimizes production image size by excluding build dependencies
- Proper npm cleanup (cache clean, package*.json removal) reduces layer bloat
- Explicit workdir and COPY operations with ownership flags (line 30-31) maintain clarity
The structure aligns well with the publish workflow's intent to create optimized, reproducible Docker images.
Also applies to: 17-21, 24-24, 30-31
33-36: Port exposure and entrypoint configuration align with MailDev defaults.The exposed ports (1080 for web UI, 1025 for SMTP) and the
maildeventrypoint with web/smtp options are correct for MailDev's typical usage patterns. This is appropriate for the dependency use case described in the PR objectives (appwrite/appwrite docker-compose integration).
2-2: I need to gather information about Alpine 3.22 stability and MailDev compatibility. Let me search for this information and inspect the Dockerfile.Now let me check the actual Dockerfile to verify the MailDev version being used:
Alpine 3.22 is stable and compatible with MailDev v2.2.1.
Alpine releases a new stable branch every May and November, with the main repository typically supported for 2 years. Alpine 3.22 includes Node.js 22.16 LTS, which exceeds MailDev's requirements. MailDev v2.2.1 was released in December 2024 with security fixes and dependency upgrades. MailDev v2.0.0 and later require Node v16 LTS or higher.
Your Dockerfile pins both Alpine 3.22 and MailDev v2.2.1, which are both current stable versions. The configuration is sound.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 5
🧹 Nitpick comments (1)
.github/workflows/build-and-push.yml (1)
3-10: Consider adding Docker image cache for faster multi-arch builds.Multi-architecture builds can be time-consuming. Adding cache configuration with
cache-from: type=ghaandcache-to: type=gha,mode=maxcan significantly accelerate subsequent builds by leveraging GitHub's cache service.Apply this diff to the build-push step:
- name: Build and push - uses: docker/build-push-action@v6 + uses: docker/build-push-action@v6 with: context: . platforms: linux/amd64,linux/arm64 push: true tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ env.TAG }} + cache-from: type=gha + cache-to: type=gha,mode=max
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/build-and-push.yml(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.8)
.github/workflows/build-and-push.yml
17-17: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
20-20: the runner of "docker/login-action@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
26-26: the runner of "docker/setup-qemu-action@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
29-29: the runner of "docker/setup-buildx-action@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
32-32: the runner of "docker/build-push-action@v4" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🔇 Additional comments (1)
.github/workflows/build-and-push.yml (1)
22-23: Verify Docker Hub secrets are configured in the repository.The workflow references
${{ secrets.DOCKERHUB_USERNAME }}and${{ secrets.DOCKERHUB_TOKEN }}, but the PR notes indicate these secrets must be added as a blocker. Ensure these repository secrets are configured before this workflow can successfully push to Docker Hub.
What does this PR do?
It introduces version pinning of the maildev version used as wel as adding a pipeline that takes cares of building the image and pushing it to dockerhub with a tag as a trigger.
Blocker:
Test Plan
Locally built and tested the image. We can subsequently use the image within the docker-compose file on the appwrite/appwrite side.
Related PRs and Issues
Creating the appwrite/appwrite docker-compose changes after the publishing of the images (as it is depending on the image being present in the tests.
Have you read the Contributing Guidelines on issues?
Yes
Summary by CodeRabbit