Problem: base stage had provenance/cache that app doesn't
Solution: Match base settings to app settings
Both stages now:
provenance: false
sbom: false
This matches what worked before!
Solution to 413 Payload Too Large:
✅ Same repository: peikarband/landing
✅ Different tags: base, latest, {commit}
Images:
• hub.peikarband.ir/peikarband/landing:base (base image)
• hub.peikarband.ir/peikarband/landing:latest (app)
• hub.peikarband.ir/peikarband/landing:{commit} (app)
No new repo creation, no permission issues!
Before: hub.peikarband.ir/peikarband/base:latest
After: hub.peikarband.ir/peikarband/landing:base
This solves the 413 error because:
✅ Same repository (no new repo creation)
✅ Just different tags
✅ No permission/quota issues
Images:
• hub.peikarband.ir/peikarband/landing:base
• hub.peikarband.ir/peikarband/landing:latest
• hub.peikarband.ir/peikarband/landing:{commit}
Problem:
• 413 Payload Too Large error
• Harbor doesn't handle provenance/sbom metadata well
Solution:
✅ provenance: false (already was)
✅ sbom: false (new - disables SBOM generation)
✅ No cache settings (simpler, more compatible)
This makes images compatible with Harbor registry!
Pipeline now handles base image automatically:
✅ ensure-base-image:
• Checks if Dockerfile.base changed
• Only rebuilds if needed
• Saves ~10 minutes when unchanged
✅ build-and-push-app:
• Uses base image
• Fast build (~3 minutes)
✅ verify-images:
• Confirms both images exist
• Shows available tags
Behavior:
─────────
1️⃣ Dockerfile.base changed:
→ Build base (~10 min)
→ Build app (~3 min)
→ Total: ~13 min
2️⃣ Only code changed:
→ Skip base (path filter)
→ Build app (~3 min)
→ Total: ~3 min ✅
This is the smart solution we wanted!
Problem: Docker-in-Docker doesn't work in Woodpecker alpine image
Solution:
- Dockerfile now self-contained (installs Node.js, bun directly)
- No dependency on external base image
- Build always works
- Simpler and more reliable
Trade-off:
- Build time: ~8-10 minutes (but reliable)
- No complex base image management
- Easier to maintain
For future optimization:
- Use .woodpecker-base.yml separately to build base
- Then switch back to base image usage
- But for now, this JUST WORKS
- Use 'docker pull' to check if base exists
- If exists: skip build (saves ~10 minutes) ✅
- If not exists: build automatically
- Single stage that handles both check and build
- No authentication issues (uses docker login)
Behavior:
✓ Base exists → Skip (~30 seconds check + 3 min app)
✓ Base missing → Build base (~10 min) + app (~3 min)
This is the REAL solution we wanted!
- Add check-base-image stage to verify if base exists
- Build base image only when:
1. Dockerfile.base changes (path condition)
2. .woodpecker.yml changes
3. Manual trigger
- Saves ~10 minutes on normal builds
- First time or after base changes: builds base
- Normal commits: skips base, only builds app
Behavior:
✓ Normal push: skip base (~3 min)
✓ Dockerfile.base change: build base (~12 min)
✓ Manual trigger: build base
- Remove cache_from and cache_to that cause parsing errors
- Keep pull: true for layer caching
- Simpler configuration that works reliably
- Docker will still use local cache automatically
Error was: type required form> "ref=..."
Cause: Woodpecker plugin doesn't support complex cache syntax
- Always build base image first (with cache for speed)
- If base exists in registry, uses cache (~30 sec)
- If base doesn't exist, builds from scratch (~10 min)
- Then builds and pushes application image
- Self-healing: no manual intervention needed
Pipeline flow:
1. build-base-image (always, with cache)
2. build-image (app)
3. push-image (with multi-tags)
4. verify-push
5. notify
First run: ~12 minutes (base + app)
Subsequent: ~3 minutes (cached base + app)
- Pre-install bun with retry mechanism before reflex export
- Add bun to PATH to ensure reflex can find it
- Fixes connection reset errors during Docker build
