-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathdecisions.jsonl
More file actions
5 lines (5 loc) · 5.15 KB
/
decisions.jsonl
File metadata and controls
5 lines (5 loc) · 5.15 KB
1
2
3
4
5
{"id":"modware-stock-5z6","title":"use justfile for multi-arch build orchestration","description":"## Decision\n\nUse justfile (just command runner) to provide standardized recipes for building, testing, and pushing multi-architecture images.\n\n## Rationale\n\n- Simple, readable task definitions without Makefile complexity.\n- Variable-based design (name, namespace, dockerfile, platforms) makes recipes reusable across services with minimal changes.\n- Recipes are self-documenting via just --list.\n- Supports importing shared recipe files (just import) for future cross-repo reuse.\n\n## Alternatives Considered\n\n- **Makefile**: Verbose syntax, whitespace-sensitive, less readable.\n- **Shell scripts**: No dependency/ordering support, harder to discover available tasks.\n- **Task (taskfile.dev)**: YAML-based, more overhead for simple recipes.\n\n## Affects\n\n- All local build and push workflows; CI can call just recipes for consistency","status":"open","priority":3,"issue_type":"task","owner":"siddhartha-basu@northwestern.edu","created_at":"2026-02-20T14:15:45.953262-06:00","created_by":"Siddhartha Basu","updated_at":"2026-02-20T14:15:45.953262-06:00","labels":["decision"]}
{"id":"modware-stock-bmn","title":"use docker buildx over Apple container tool for multi-arch builds","description":"## Decision\n\nUse docker buildx exclusively for multi-architecture image builds on all platforms.\n\n## Rationale\n\nApple's container tool has serious DNS resolution failures during builds — packages cannot be fetched from Alpine APK or Go module proxy. docker buildx works reliably on both macOS and Linux.\n\n## Alternatives Considered\n\n- **apple/container (OS-conditional routing)**: Implemented first but abandoned due to DNS failures blocking apk add and go mod download inside the build.\n- **Separate CI-only builds**: Rejected — developers need to build locally to test.\n\n## Affects\n\n- justfile recipes: build-multiarch, build-amd64, build-arm64, push-ghcr","status":"open","priority":1,"issue_type":"task","owner":"siddhartha-basu@northwestern.edu","created_at":"2026-02-20T14:15:43.517913-06:00","created_by":"Siddhartha Basu","updated_at":"2026-02-20T14:15:43.517913-06:00","labels":["decision"]}
{"id":"modware-stock-d1h","title":"apply UPX compression on amd64 only, skip on arm64","description":"## Decision\n\nUPX binary compression is applied conditionally: only when TARGETARCH=amd64.\n\n## Rationale\n\nUPX is not reliable on arm64 — it causes build failures and corrupted binaries in Alpine + QEMU emulation scenarios. amd64 builds benefit from ~60-70% size reduction with no such issues.\n\n## Alternatives Considered\n\n- **UPX on all architectures**: Breaks arm64 builds.\n- **No UPX at all**: Larger amd64 image for no benefit.\n- **upx --best on arm64 only**: Unreliable; dropped.\n\n## Affects\n\n- Dockerfile.multiarch builder stage RUN steps","status":"open","priority":2,"issue_type":"task","owner":"siddhartha-basu@northwestern.edu","created_at":"2026-02-20T14:15:44.088769-06:00","created_by":"Siddhartha Basu","updated_at":"2026-02-20T14:15:44.088769-06:00","labels":["decision"]}
{"id":"modware-stock-f5l","title":"cross-compile using BUILDPLATFORM/TARGETPLATFORM Docker args","description":"## Decision\n\nBuilder stage uses --platform=\\$BUILDPLATFORM (native host) and cross-compiles via GOOS/GOARCH targeting \\$TARGETOS/\\$TARGETARCH.\n\n## Rationale\n\nBuilding on the native host platform avoids slow QEMU emulation. Go cross-compilation is first-class and does not require emulation. amd64 builds on Apple Silicon are 5-10x faster this way.\n\n## Alternatives Considered\n\n- **QEMU emulation (--platform=\\$TARGETPLATFORM for builder)**: Slow, especially for amd64 on arm64 host.\n- **Separate native CI runners per arch**: More complex pipeline, not needed given Go's cross-compilation.\n\n## Affects\n\n- Dockerfile.multiarch FROM builder stage\n- go build RUN step (CGO_ENABLED=0 required)","status":"open","priority":2,"issue_type":"task","owner":"siddhartha-basu@northwestern.edu","created_at":"2026-02-20T14:15:45.324019-06:00","created_by":"Siddhartha Basu","updated_at":"2026-02-20T14:15:45.324019-06:00","labels":["decision"]}
{"id":"modware-stock-yqs","title":"use Alpine builder and distroless/static runtime in Dockerfile","description":"## Decision\n\nTwo-stage Dockerfile: golang:1.24-alpine as builder, gcr.io/distroless/static-debian12 as runtime.\n\n## Rationale\n\n- Alpine gives apk tooling (upx, etc.) during build with a small footprint.\n- distroless/static has no shell, no package manager, minimal attack surface — appropriate for a static Go binary.\n- The combination produces a minimal, secure runtime image.\n\n## Alternatives Considered\n\n- **scratch**: No CA certificates or timezone data; painful for services making HTTPS calls.\n- **Alpine runtime**: Larger image, shell present (unnecessary attack surface).\n- **debian-slim runtime**: Larger, not needed for CGO_ENABLED=0 binary.\n\n## Affects\n\n- Dockerfile.multiarch both stages","status":"open","priority":2,"issue_type":"task","owner":"siddhartha-basu@northwestern.edu","created_at":"2026-02-20T14:15:44.745381-06:00","created_by":"Siddhartha Basu","updated_at":"2026-02-20T14:15:44.745381-06:00","labels":["decision"]}