Add Pluton app Docker setup and CI workflow#130
Conversation
Introduces Pluton app with Dockerfile, build script, config, version file, and docker-compose for deployment. Adds GitHub Actions workflow for automated build and release of the Pluton Docker image supporting multiple architectures.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughAdds Pluton app packaging and deployment: multi-stage Dockerfile, docker-compose, config and VERSION, build script and entrypoint, plus a GitHub Actions workflow to conditionally compute version, check registry, and build/push multi-arch images. Changes
Sequence DiagramsequenceDiagram
participant Event as Trigger (dispatch/schedule/push)
participant GH as GitHub Actions
participant Check as check-pluton-release
participant API as GitHub API
participant Hub as Docker Hub
participant Build as build-and-push
Event->>GH: start workflow
GH->>Check: run
alt dispatch with pluton_version
Check->>Check: use provided pluton_version
else schedule or push
Check->>API: request main branch content
API-->>Check: respond with commit SHA
Check->>Check: derive pluton_version (7-char SHA)
end
alt scheduled run
Check->>Hub: query tag existence
Hub-->>Check: exists / not exists
Check->>Check: set should_build accordingly
else dispatch or push
Check->>Check: should_build = true
end
Check-->>GH: emit pluton_version, should_build
alt should_build == true
GH->>Build: run build-and-push
Build->>Build: setup QEMU, buildx, metadata
Build->>Hub: build & push multi-arch image(s)
Hub-->>Build: push result
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Poem
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (4)
Apps/pluton/VERSION (1)
1-1: Add trailing newline to VERSION file.The VERSION file is read by build.sh and should follow Unix conventions by ending with a newline character.
-0.0.1 +0.0.1(Ensure one newline at end of file)
Apps/pluton/compose/docker-compose.yml (1)
3-4: Align image versioning with VERSION file.The docker-compose build context and image tag should align with the versioning strategy defined in Apps/pluton/VERSION and build.sh. Currently the image is hardcoded to
latest, but build.sh tags with both${VERSION}andlatest. Consider using an environment variable for the version tag to keep deployment configurations flexible.- image: bigbeartechworld/big-bear-pluton:latest + image: ${IMAGE_TAG:-bigbeartechworld/big-bear-pluton:latest}Then users can set
IMAGE_TAG=bigbeartechworld/big-bear-pluton:0.0.1when deploying specific versions.Apps/pluton/Dockerfile (2)
51-53: Remove duplicate ARG declarations.ARG definitions for TARGETARCH, RESTIC_VERSION, and RCLONE_VERSION are declared twice (lines 7-9 and 51-53). Consolidate to a single declaration in the Stage 4 section where they are used.
# Stage 4: Runner FROM node:24-alpine AS runner WORKDIR /app RUN apk add --no-cache curl ca-certificates fuse3 bash # Create data directory RUN mkdir -p /data /data/logs /data/db /data/config # Download specific versions of restic and rclone binaries ARG TARGETARCH -ARG RESTIC_VERSION=0.18.1 -ARG RCLONE_VERSION=1.71.2Keep the declarations at lines 51-53 and remove the duplicates at lines 7-9, or consolidate as needed for build argument flow.
84-92: Improve wrapper script creation for maintainability.The wrapper scripts are created with individual echo commands (lines 84-92), making them fragile and difficult to maintain. Use a heredoc or separate script file for clarity.
# Create Pluton wrapper scripts for rclone and restic -RUN echo '#!/bin/sh' > /usr/local/bin/prclone && \ - echo '# Pluton Wrapper for rclone' >> /usr/local/bin/prclone && \ - echo 'exec /usr/local/bin/rclone --config /data/config/rclone.conf "$@"' >> /usr/local/bin/prclone && \ - chmod +x /usr/local/bin/prclone && \ - echo '#!/bin/sh' > /usr/local/bin/prestic && \ - echo '# Pluton Wrapper for restic' >> /usr/local/bin/prestic && \ - echo 'export RCLONE_CONFIG=/data/config/rclone.conf' >> /usr/local/bin/prestic && \ - echo 'exec /usr/local/bin/restic -o rclone.program=/usr/local/bin/rclone "$@"' >> /usr/local/bin/prestic && \ - chmod +x /usr/local/bin/prestic +RUN cat > /usr/local/bin/prclone <<'EOF' && \ +#!/bin/sh +# Pluton Wrapper for rclone +exec /usr/local/bin/rclone --config /data/config/rclone.conf "$@" +EOF +chmod +x /usr/local/bin/prclone && \ +cat > /usr/local/bin/prestic <<'EOF' && \ +#!/bin/sh +# Pluton Wrapper for restic +export RCLONE_CONFIG=/data/config/rclone.conf +exec /usr/local/bin/restic -o rclone.program=/usr/local/bin/rclone "$@" +EOF +chmod +x /usr/local/bin/prestic
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to Reviews > Disable Cache setting
Knowledge base: Disabled due to data retention organization setting
📒 Files selected for processing (6)
.github/workflows/build_and_release_for_pluton.yaml(1 hunks)Apps/pluton/Dockerfile(1 hunks)Apps/pluton/VERSION(1 hunks)Apps/pluton/compose/docker-compose.yml(1 hunks)Apps/pluton/config/config.json(1 hunks)Apps/pluton/scripts/build.sh(1 hunks)
🔇 Additional comments (3)
Apps/pluton/config/config.json (1)
1-44: Good security guidance in configuration template.The configuration file includes clear warnings about changing default credentials (line 40) and notes about strong secrets. This is a well-structured descriptor for Pluton deployment.
Apps/pluton/scripts/build.sh (1)
1-34: Good local build script with clear UX and error handling.The script includes appropriate error handling (set -e), directory validation, and colorized output. Once the VERSION file trailing newline is fixed, this script will be production-ready for local builds.
.github/workflows/build_and_release_for_pluton.yaml (1)
1-112: Good multi-platform CI/CD workflow structure with proper caching.The workflow effectively separates the check and build phases, supports manual and scheduled triggers, and implements multi-platform builds (amd64, arm64) with GitHub Actions caching. Once external API error handling is added, this workflow will be resilient and production-ready.
Enhances error handling and validation in the GitHub Actions workflow for Pluton, including better checks for API responses and Docker Hub connectivity. Updates the Dockerfile to support version pinning, adds checksum validation for downloaded binaries, improves directory permissions, and introduces an entrypoint script to ensure proper runtime permissions and execution as the node user.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
Apps/pluton/Dockerfile (1)
97-105: Wrapper scripts: consider consolidation for readability.The prclone and prestic wrapper scripts are functional but the line-by-line echo approach is verbose. Consider a more concise approach using heredocs or a single tee/cat command per script for better maintainability.
For example:
# Create Pluton wrapper scripts for rclone and restic -RUN echo '#!/bin/sh' > /usr/local/bin/prclone && \ - echo '# Pluton Wrapper for rclone' >> /usr/local/bin/prclone && \ - echo 'exec /usr/local/bin/rclone --config /data/config/rclone.conf "$@"' >> /usr/local/bin/prclone && \ - chmod +x /usr/local/bin/prclone && \ - echo '#!/bin/sh' > /usr/local/bin/prestic && \ - echo '# Pluton Wrapper for restic' >> /usr/local/bin/prestic && \ - echo 'export RCLONE_CONFIG=/data/config/rclone.conf' >> /usr/local/bin/prestic && \ - echo 'exec /usr/local/bin/restic -o rclone.program=/usr/local/bin/rclone "$@"' >> /usr/local/bin/prestic && \ - chmod +x /usr/local/bin/prestic +RUN cat > /usr/local/bin/prclone << 'EOF' && chmod +x /usr/local/bin/prclone +#!/bin/sh +# Pluton Wrapper for rclone +exec /usr/local/bin/rclone --config /data/config/rclone.conf "$@" +EOF +cat > /usr/local/bin/prestic << 'EOF' && chmod +x /usr/local/bin/prestic +#!/bin/sh +# Pluton Wrapper for restic +export RCLONE_CONFIG=/data/config/rclone.conf +exec /usr/local/bin/restic -o rclone.program=/usr/local/bin/rclone "$@" +EOFThis approach improves readability and reduces line count within the RUN layer.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to Reviews > Disable Cache setting
Knowledge base: Disabled due to data retention organization setting
📒 Files selected for processing (3)
.github/workflows/build_and_release_for_pluton.yaml(1 hunks)Apps/pluton/Dockerfile(1 hunks)Apps/pluton/entrypoint.sh(1 hunks)
🔇 Additional comments (5)
Apps/pluton/entrypoint.sh (1)
1-7: Solid entrypoint wrapper for permission setup and user switching.The script correctly initializes /data ownership and executes the command as the non-root node user via su-exec. This pattern is standard and aligns with the Dockerfile's setup (su-exec package installed, directories pre-created and chowned).
Apps/pluton/Dockerfile (1)
59-94: Binary verification is robust and addresses prior security feedback.Checksum verification for restic and rclone is now in place using SHA256 with architecture-specific hashes. This is a significant improvement—the binaries are validated before installation, and unset statements clear version variables after use. Well done.
.github/workflows/build_and_release_for_pluton.yaml (3)
38-60: Excellent error handling for GitHub API call with proper validation.The get_version step now includes HTTP code validation, response content checking, and SHA format validation against the regex
^[0-9a-f]{7}$. This ensures that empty, malformed, or failed API responses are caught and the workflow exits cleanly. The substring slicing approach on lines 39–40 to extract HTTP code is correct and efficient.
68-82: Docker Hub API check includes timeout and proper error detection.The check_image step adds a 10-second timeout and handles curl exit failures (code "000" or empty). This prevents hanging on API failures and avoids silent failures that would cause should_build to be incorrectly set. Conditional logic correctly triggers only on schedule.
87-93: Build decision logic is sound and avoids redundant builds.The should_build step correctly triggers on workflow_dispatch and push (always build), and on schedule only if the image doesn't already exist on Docker Hub. This prevents redundant builds while allowing manual overrides and automatic updates on code changes.
1 participant
This pull request introduces the initial setup for integrating the Pluton backup solution into the project. It adds all necessary configuration, build, and deployment files to support building, running, and releasing Pluton as a Docker container. The changes are organized to provide a production-ready Docker workflow, including multi-architecture support, environment configuration, and documentation metadata.
Pluton Docker Integration and Release Workflow
Docker Workflow & Automation:
.github/workflows/build_and_release_for_pluton.yamlto automate building and releasing the Pluton Docker image on pushes, scheduled events, and manual triggers, with logic to avoid unnecessary builds if the image already exists.Docker Image & Build System:
DockerfileinApps/plutonto build and package Pluton, including frontend and backend, with support for bothamd64andarm64architectures and integration of restic and rclone binaries.scripts/build.shfor local building of the Docker image with clear output and error handling.Deployment & Configuration:
compose/docker-compose.ymlfor easy deployment, including environment variables, persistent data volume, healthchecks, and port mapping for the Pluton service.config/config.jsonwith metadata, documentation links, environment variable descriptions, and usage notes for Pluton.Version Management:
VERSIONfile to track the Pluton app version used in builds and tagging.