Repo transferred from the-luap/picpeak → PicPeak/picpeak. Docker images
publish to ghcr.io/picpeak/picpeak/{backend,frontend} (lowercase, per the
GHCR canonical form computed by docker-build.yml's `${GITHUB_REPOSITORY,,}`).
Sweep covers:
- docker-compose.production.yml + Dockerfiles → new image registry path
- README, CONTRIBUTING, SECURITY, SIMPLE_SETUP, scripts/picpeak-setup.sh
→ new GitHub URLs
- Update-check / release-notes services (updateCheckService,
environmentService, updateNotificationService, adminSystem,
UpdateNotification, githubReleaseUrl) → GitHub API + tag URLs use the
canonical PicPeak/picpeak path
- Issue templates + README-DOCKER + workflow README → updated package URLs
- One commit-context comment in migrations/090 + customerAccountsService
CHANGELOG.md is intentionally untouched (historical release entries are
immutable; GitHub auto-redirects the old URLs indefinitely).
CLAUDE.md keeps the bare `(the-luap)` reference — that's the maintainer's
personal handle, not a repo URL.
22 files, 48/48 line swaps (every change is a 1:1 URL replacement).
5.7 KiB
Docker Build and Push Workflow
This GitHub Actions workflow automatically builds and pushes Docker images for both the backend and frontend to GitHub Container Registry (ghcr.io).
Features
- 🔧 Automatic builds on push to main/develop branches, PRs, and releases
- 🏗️ Multi-architecture support (linux/amd64 and linux/arm64)
- 🏷️ Smart tagging based on branches, versions, and commits
- 🔒 Security scanning with Trivy vulnerability scanner
- 💾 Build caching for faster subsequent builds
- 📊 Build summaries in GitHub Actions UI
Authentication
The workflow uses the built-in GITHUB_TOKEN for authentication with GitHub Container Registry. No additional setup or personal access tokens are required.
Required Permissions
The workflow automatically sets the necessary permissions:
contents: read- To checkout the repositorypackages: write- To push images to ghcr.iosecurity-events: write- To upload security scan results
Image Tags
Images are automatically tagged based on the trigger event:
| Event | Tags Generated |
|---|---|
| Push to main | latest, main, main-<short-sha> |
| Push to develop | develop, develop-<short-sha> |
| Pull Request | pr-<number> |
| Release (v1.2.3) | 1.2.3, 1.2, 1, latest |
| Manual trigger | Based on branch + optional push |
Usage
Pull Images
Once published, images can be pulled using:
# Pull backend image
docker pull ghcr.io/picpeak/picpeak/backend:latest
# Pull frontend image
docker pull ghcr.io/picpeak/picpeak/frontend:latest
# Pull specific version
docker pull ghcr.io/picpeak/picpeak/backend:v1.0.0
# Pull for specific architecture
docker pull --platform linux/arm64 ghcr.io/picpeak/picpeak/backend:latest
Using in Docker Compose
version: '3.8'
services:
backend:
image: ghcr.io/picpeak/picpeak/backend:latest
environment:
- NODE_ENV=production
ports:
- "3001:3000"
frontend:
image: ghcr.io/picpeak/picpeak/frontend:latest
ports:
- "80:80"
Using in Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
name: picpeak-backend
spec:
replicas: 3
template:
spec:
containers:
- name: backend
image: ghcr.io/picpeak/picpeak/backend:latest
imagePullPolicy: Always
Manual Workflow Trigger
You can manually trigger the workflow from the Actions tab:
- Go to Actions → "Build and Push Docker Images"
- Click "Run workflow"
- Select branch and whether to push images
- Click "Run workflow"
Security Scanning
The workflow includes Trivy vulnerability scanning that:
- Scans for CRITICAL and HIGH severity vulnerabilities
- Uploads results to GitHub Security tab
- Available under Security → Code scanning alerts
Build Optimization
The workflow uses several optimization techniques:
- GitHub Actions Cache: Speeds up builds by caching layers
- Multi-stage builds: Reduces final image size
- Parallel builds: Backend and frontend build simultaneously
- Smart rebuilds: Only rebuilds changed components
Troubleshooting
Permission Denied Errors
If you encounter permission errors when pushing images:
-
First-time setup: The first push creates a private package. You may need to:
- Go to your package settings at
https://github.com/users/YOUR_USERNAME/packages - Link the package to your repository
- Set package visibility (public/private)
- Go to your package settings at
-
Organization repositories: Ensure the organization allows GitHub Actions to create packages
Build Failures
Check the workflow logs in the Actions tab for detailed error messages. Common issues:
- Missing dependencies in package.json
- Dockerfile syntax errors
- Network issues during package installation
Image Not Found
If images aren't visible after successful push:
- Check package visibility settings
- Ensure you're authenticated to pull private images:
echo $GITHUB_TOKEN | docker login ghcr.io -u YOUR_USERNAME --password-stdin
Package Management
View Packages
Your Docker images are available at:
- Backend:
https://github.com/orgs/PicPeak/packages/container/package/picpeak%2Fbackend - Frontend:
https://github.com/orgs/PicPeak/packages/container/package/picpeak%2Ffrontend
Delete Old Versions
To save storage, you can delete old versions:
- Go to package settings
- Click on "Manage versions"
- Select versions to delete
- Click "Delete selected versions"
Set Retention Policy
Configure automatic cleanup in package settings:
- Go to package settings
- Click on "Manage Actions access"
- Set retention days for untagged versions
Best Practices
- Use semantic versioning for releases (e.g., v1.2.3)
- Test images locally before pushing to production
- Monitor security alerts from Trivy scans
- Clean up old images regularly to save storage
- Use specific tags in production (avoid
latest)
Advanced Configuration
Custom Registry
To use a different registry, update the workflow:
env:
REGISTRY: docker.io # or your custom registry
BACKEND_IMAGE_NAME: yourusername/picpeak-backend
Additional Platforms
To build for more platforms:
platforms: linux/amd64,linux/arm64,linux/arm/v7
Custom Build Arguments
Add build arguments in the workflow:
build-args: |
NODE_VERSION=20
API_URL=${{ secrets.API_URL }}