Rockachopa/Timmy-time-dashboard
1
0
Fork 2
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

[loop-generated] [optimization] Optimize Docker build pipeline — reduce image size and build time #1436

New Issue
Closed
opened 2026-03-24 13:22:17 +00:00 by Timmy · 1 comment
Timmy commented 2026-03-24 13:22:17 +00:00
Owner
Copy Link

Priority: High
Impact: Build efficiency and resource usage

Context:
Docker images for Timmy services may be oversized and slow to build, impacting development velocity and deployment efficiency.

Proposed approach:

  1. Audit current Dockerfile(s) for optimization opportunities
  2. Implement multi-stage builds to reduce final image size
  3. Optimize layer caching and minimize layers
  4. Use .dockerignore to exclude unnecessary files
  5. Consider Alpine Linux or distroless base images
  6. Add build time and image size metrics

Files likely involved:

  • Dockerfile (if exists)
  • docker-compose.yml (if exists)
  • .dockerignore
  • Build scripts

Acceptance criteria:

  • Reduced Docker image size by at least 30%
  • Faster build times through improved caching
  • Documentation of optimization techniques used
  • Maintained functionality with optimized images

Dependencies: None
Estimated effort: Medium (2-4 files, clear optimization targets)

**Priority:** High **Impact:** Build efficiency and resource usage **Context:** Docker images for Timmy services may be oversized and slow to build, impacting development velocity and deployment efficiency. **Proposed approach:** 1. Audit current Dockerfile(s) for optimization opportunities 2. Implement multi-stage builds to reduce final image size 3. Optimize layer caching and minimize layers 4. Use .dockerignore to exclude unnecessary files 5. Consider Alpine Linux or distroless base images 6. Add build time and image size metrics **Files likely involved:** - `Dockerfile` (if exists) - `docker-compose.yml` (if exists) - `.dockerignore` - Build scripts **Acceptance criteria:** - Reduced Docker image size by at least 30% - Faster build times through improved caching - Documentation of optimization techniques used - Maintained functionality with optimized images **Dependencies:** None **Estimated effort:** Medium (2-4 files, clear optimization targets)
Timmy commented 2026-03-24 13:36:27 +00:00
Author
Owner
Copy Link

Implementation Instructions for Kimi

ANALYSIS COMPLETED: The codebase has 6 Dockerfile variants and 3 docker-compose files. The main Dockerfile uses the older single-stage pattern while docker/Dockerfile.dashboard already uses multi-stage builds.

Files to Optimize:

  1. Dockerfile (main image) - Currently 34 lines, single-stage build

    • Uses python:3.11-slim base
    • Installs gcc, git, bash, curl, fonts-dejavu-core, nodejs
    • Pre-installs all poetry deps but removes source files
    • OPTIMIZATION NEEDED: Convert to multi-stage build

  2. docker/Dockerfile.agent - Review and optimize

  3. docker/Dockerfile.ollama - Review and optimize

  4. docker/Dockerfile.test - Review and optimize

  5. docker/Dockerfile.openfang - Review and optimize

  6. .dockerignore - Already comprehensive, may need tweaks

Optimization Strategy:

Step 1: Convert main Dockerfile to multi-stage

  • Use docker/Dockerfile.dashboard as the reference pattern
  • Builder stage: Install build deps, export poetry requirements
  • Runtime stage: Copy only installed packages + source
  • Remove build tools from final image
  • Add non-root user for security
  • Add health check

Step 2: Review other Dockerfiles

  • Apply similar multi-stage patterns where beneficial
  • Use consistent base images (prefer python:3.12-slim)
  • Remove unnecessary packages from final stages
  • Ensure proper layer caching

Step 3: Measure improvements

  • Document before/after image sizes
  • Test build times with and without cache
  • Verify all functionality preserved

Acceptance Criteria:

  • Main Dockerfile reduced by 30%+ in final image size
  • Consistent multi-stage pattern across relevant Dockerfiles
  • Faster builds through better layer caching
  • Maintained functionality (all tests pass)
  • Updated documentation with optimization notes

PRIORITY: This is a high-impact optimization that will improve developer velocity and deployment efficiency. Focus on the main Dockerfile first, then optimize others as time permits.

## Implementation Instructions for Kimi **ANALYSIS COMPLETED:** The codebase has 6 Dockerfile variants and 3 docker-compose files. The main `Dockerfile` uses the older single-stage pattern while `docker/Dockerfile.dashboard` already uses multi-stage builds. ### Files to Optimize: 1. **`Dockerfile`** (main image) - Currently 34 lines, single-stage build - Uses `python:3.11-slim` base - Installs gcc, git, bash, curl, fonts-dejavu-core, nodejs - Pre-installs all poetry deps but removes source files - **OPTIMIZATION NEEDED:** Convert to multi-stage build 2. **`docker/Dockerfile.agent`** - Review and optimize 3. **`docker/Dockerfile.ollama`** - Review and optimize 4. **`docker/Dockerfile.test`** - Review and optimize 5. **`docker/Dockerfile.openfang`** - Review and optimize 6. **`.dockerignore`** - Already comprehensive, may need tweaks ### Optimization Strategy: **Step 1: Convert main `Dockerfile` to multi-stage** - Use `docker/Dockerfile.dashboard` as the reference pattern - Builder stage: Install build deps, export poetry requirements - Runtime stage: Copy only installed packages + source - Remove build tools from final image - Add non-root user for security - Add health check **Step 2: Review other Dockerfiles** - Apply similar multi-stage patterns where beneficial - Use consistent base images (prefer python:3.12-slim) - Remove unnecessary packages from final stages - Ensure proper layer caching **Step 3: Measure improvements** - Document before/after image sizes - Test build times with and without cache - Verify all functionality preserved ### Acceptance Criteria: - Main Dockerfile reduced by 30%+ in final image size - Consistent multi-stage pattern across relevant Dockerfiles - Faster builds through better layer caching - Maintained functionality (all tests pass) - Updated documentation with optimization notes **PRIORITY:** This is a high-impact optimization that will improve developer velocity and deployment efficiency. Focus on the main `Dockerfile` first, then optimize others as time permits.
kimi was assigned by Timmy 2026-03-24 13:36:32 +00:00
kimi was unassigned by Timmy 2026-03-24 19:32:10 +00:00
Timmy closed this issue 2026-03-24 21:54:03 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
222-epic
Workshop: Timmy as Presence (Epic #222)
 actionable
Has a concrete code/config task extracted
 assigned-claude
Issue currently assigned to Claude agent — do not assign to another agent
 assigned-gemini
Issue currently assigned to Gemini agent — do not assign to another agent
 assigned-groq
assigned-kimi
Issue currently assigned to Kimi agent — do not assign to another agent
 assigned-manus
Issue currently assigned to Manus agent — do not assign to another agent
 claude-ready
consolidation
Part of a consolidation epic
 deprioritized
Keep open but not blocking P0 work
 deprioritized
Keep open but not blocking P0 work
 duplicate
Duplicate of another issue
 gemini-review
Auto-generated by Gemini, needs relevance review
 groq-ready
harness
Core product: agent framework, heartbeat, inference, memory
 heartbeat
Harness: Agent heartbeat loop
 inference
Harness: Inference and model routing
 infrastructure
Supporting stage: dashboard, CI/CD, deployment, DNS
 kimi-ready
Scoped and ready for Kimi to pick up
 memory-session
Harness: Memory and session crystallization
 morrowind
Harness: Morrowind embodiment
 needs-design
Needs architectural design before implementation
 needs-extraction
Philosophy with unextracted engineering work
 p0-critical
Priority 0: Must fix now
 p1-important
Priority 1: Important, next sprint
 p2-backlog
Priority 2: Backlog, do when time permits
 philosophy
Philosophical foundation — informs architecture decisions
 rejected-direction
Closed: rejected or superseded direction
 seed:know-purpose
Three Seeds: KNOW YOUR PURPOSE
 seed:serve-real
Three Seeds: SERVE THE REAL
 seed:tell-truth
Three Seeds: TELL THE TRUTH
 sovereignty
Harness: Sovereignty stack
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Timmy claude grok kimi manus perplexity Rockachopa
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Rockachopa/Timmy-time-dashboard#1436
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?