Steve Degosserie
9a5404de82
refactor: Consolidate and optimize Docker image architecture ( #233 )
...
## Overview
This PR consolidates and optimizes the Docker build system, reducing
redundancy and improving CI/CD performance. The changes eliminate
duplicate Dockerfiles, introduce a flexible build template, and optimize
release builds to reuse CI artifacts.
## Changes Summary
### 🐳 Docker Images Restructured
**Before:** 5 Dockerfiles with significant overlap
**After:** 4 focused images + 1 utility
#### Final Structure:
1. **`operator/Dockerfile`** ✨ Updated
- **Standard operator image** for CI and release builds
- Minimal node image (accepts pre-built binaries)
- GHCR: `ghcr.io/datahaven-xyz/datahaven/datahaven` (CI)
- DockerHub: `datahavenxyz/datahaven` (releases)
2. **`docker/datahaven-build.Dockerfile`** (moved from
`operator/Dockerfile`)
- Full source-to-binary build for manual releases
- DockerHub: `datahavenxyz/datahaven:{label}`
- Supports custom RUSTFLAGS and fast-runtime feature
- Only used for manual workflow_dispatch builds
3. **`docker/datahaven-production.Dockerfile`** (kept)
- Binary builder for CPU-specific releases
- Used by build-prod-binary workflow template
- Supports custom target-cpu flags
4. **`docker/datahaven-dev.Dockerfile`** ✨ NEW (local dev only)
- **FOR LOCAL DEVELOPMENT/TROUBLESHOOTING ONLY**
- Includes debug tools: gdb, strace, vim, sudo
- Extra dependencies: librocksdb-dev, curl
- RUST_BACKTRACE enabled by default
- **DO NOT USE for CI or production builds**
5. **`test/docker/crossbuild-mac-libpq.dockerfile`** (kept)
- Utility for macOS → Linux cross-compilation
#### Removed (Redundant):
- ❌ `docker/datahaven.Dockerfile` → replaced by operator/Dockerfile
- ❌ `test/docker/datahaven-node-local.dockerfile` → replaced by
datahaven-dev.Dockerfile
---
### 🔄 Workflow Improvements
#### Enhanced `publish-docker` Template
- Supports both GHCR and DockerHub registries
- Flexible inputs: dockerfile, context, build-args, cache scope
- Auto-generates OCI-compliant labels
- Reduces code duplication (~70 lines → ~15 per workflow)
#### Refactored CI Pipeline
- **`docker-build-ci`**: Builds `operator/Dockerfile` → GHCR for CI/E2E
testing
- **`docker-build-release`**: Builds `operator/Dockerfile` → DockerHub
(main branch only)
- Both CI and release workflows now use the same minimal operator image
- Release builds **reuse CI binaries** instead of rebuilding from source
#### Optimized Release Workflow
The `task-docker-release` workflow now has dual modes:
**Mode 1: `workflow_call` (CI - main pushes)**
- ✅ Reuses binary from CI's build-operator task
- ✅ Uses lightweight `operator/Dockerfile`
- ✅ Tags: `latest`, `sha-{short}`
- ⚡ **Fast**: ~5 minutes (vs ~30 min previously)
**Mode 2: `workflow_dispatch` (Manual)**
- ✅ Full source build with `datahaven-build.Dockerfile`
- ✅ Custom branch and label selection
- ✅ Optional fast-runtime feature
- ✅ Tags: `PROD-{label}` or user-defined
---
### 🔧 Additional Optimizations
- Copy libpq5 from builder stage instead of reinstalling (smaller,
faster)
- Remove redundant protobuf-compiler package (use protoc v21.12
directly)
- Standardize user UID to 1000 across all runtime images
- Consistent OCI labeling and metadata
---------
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-15 01:33:20 +02:00
Facundo Farall
a86791ec1c
perf(CLI): ⚡ Add option to use local Docker build in CLI for faster iteration ( #77 )
...
In this PR:
1. Add new `datahaven-node-local.dockerfile` for building a local image
with the locally built DataHaven Node binary. This severely improves
iteration speed on running `bun cli` if there are changes in the DH
node. Previously, it relied on the published dockerfile, which builds
the Cargo project inside of it, taking +20m even with no changes.
2. Building this local dockerfile is integrated to the CLI, which now
also asks if the user wants to rebuild the local docker image of the DH
node.
3. A new script `cargo-crossbuild` is added, to be able to build the
DataHaven node Cargo project both from Mac and Linux, with the target
being `x86_64-unknown-linux-gnu`. For building from Mac, it uses `cargo
zigbuild`, so `zig` is now a dependency. Building for this target is
needed because the docker image is an Ubuntu image, so it will need to
run a linux binary.
4. Added `zig` as dependency in docs.
5. CI still uses the docker image built by the CI itself, which builds
the Cargo project inside of it. The CI can take advantage of caching for
this.
2025-05-16 18:04:40 -03:00
