fix: use full UBI9 nodejs image for frontend build stage

[jeremyeder]

Summary

• Switch the frontend Dockerfile build stage from ubi9/nodejs-20-minimal to the full ubi9/nodejs-20 image

Problem

Next.js 16 Turbopack requires native SWC binaries that depend on glibc. The ubi9/nodejs-20-minimal image lacks glibc, which causes arm64 build failures when Turbopack attempts to load its native bindings during the build stage.

Fix

Use the full ubi9/nodejs-20 image for the frontend build stage, which includes glibc and all required system libraries for SWC/Turbopack native binaries to load correctly on both amd64 and arm64 architectures.

[jeremyeder]

I hit this for the first time today, on my mac. This change seems fine.

[github-actions]

Claude Code Review

Summary

This PR fixes ARM64 build failures for the frontend component by switching from the minimal UBI9 Node.js image to the full image for the build stage. The change is surgical, well-justified, and follows the pattern established in PR e3dc83e for state-sync ARM64 compatibility.

Verdict: ✅ APPROVE - Ready to merge

Issues by Severity

🚫 Blocker Issues

None.

🔴 Critical Issues

None.

🟡 Major Issues

None.

🔵 Minor Issues

None.

Positive Highlights

1. Minimal Change Footprint - Only changes the single problematic build stage, leaving deps and runner stages using minimal images where appropriate
2. Excellent Documentation - Inline comment clearly explains WHY the full image is needed (Next.js 16 Turbopack + SWC native binaries + glibc dependency)
3. Consistent with Platform Standards - Follows the established pattern from commit e3dc83e where similar ARM64 compatibility issues were fixed for state-sync
4. Multi-Platform CI Ready - The change aligns with the existing CI pipeline that builds linux/amd64,linux/arm64 images (see .github/workflows/components-build-deploy.yml:149,164)
5. Right-Sized Solution - Uses full image ONLY for the build stage where native binaries are needed, keeps minimal images for deps and runtime (runner stage) to minimize final image size
6. Production Image Unaffected - The runner stage (line 33) still uses nodejs-20-minimal, keeping the final production image small since it only needs the compiled output

Technical Analysis

Root Cause

Next.js 16 Turbopack uses SWC (Speedy Web Compiler) which includes native Rust binaries that depend on glibc. The ubi9/nodejs-20-minimal image lacks glibc, causing ARM64 build failures when these native bindings attempt to load during the build process.

Fix Validation

The fix is correct because:

• Build stage needs glibc - SWC native binaries require it during compilation
• Runtime doesn't need it - The compiled Next.js output (copied to runner stage) doesn't require native bindings
• Multi-arch support - Both amd64 and arm64 need the same dependencies for consistent builds
• Follows ADR-0005 - Uses proper Next.js build tooling (Turbopack is Next.js's recommended bundler)

Security Considerations

✅ No security concerns:

• Using official Red Hat UBI images (trusted registry: registry.access.redhat.com)
• Maintaining principle of least privilege: minimal image for runtime, full image only where needed
• No changes to SecurityContext, user permissions, or exposed ports

Performance Impact

Minor improvement:

• Build time: Slightly longer (larger base image download)
• Runtime: No change (runner stage unchanged)
• Image size: No change to final production image (still uses minimal for runner)

Recommendations

Pre-Merge Actions

None required - ready to merge as-is.

Future Considerations (Not Blocking)

1. Monitor Next.js 17 - If/when Next.js 17 is released, validate whether Turbopack dependencies change
2. Document in ADR - Consider adding this to .claude/context/frontend-development.md as a known pattern:

   ## Dockerfile Multi-Stage Build Pattern
   - **deps stage**: minimal image (dependency installation only)
   - **builder stage**: full image (native binary compilation - SWC/Turbopack)
   - **runner stage**: minimal image (runtime execution)

3. Test ARM64 locally - If team members have Apple Silicon Macs, validate that make kind-up works after this change (should fix any existing ARM64 issues)

References

• Related Fix: Commit e3dc83e - state-sync ARM64 compatibility
• CI Pipeline: .github/workflows/components-build-deploy.yml (multi-arch builds)
• Next.js Docs: Turbopack requires native binaries (SWC for transpilation)
• CLAUDE.md: Container Images standards (lines 328-333)

---

Reviewed by: Claude Sonnet 4.5 (Code Review Agent)
Standards Applied: CLAUDE.md, .claude/context/security-standards.md, .claude/patterns/error-handling.md
Review Date: 2026-02-14

---

🔍 View AI decision process (logs available for 90 days)

📋 View memory system files loaded (click to expand)

What Amber Loaded for Code Review

Amber automatically loaded these repository standards from the memory system:

1. CLAUDE.md - Master project instructions, development standards
2. backend-development.md - Go backend, K8s integration patterns
3. frontend-development.md - NextJS, Shadcn UI, React Query patterns
4. security-standards.md - Auth, RBAC, token handling
5. k8s-client-usage.md - User token vs service account patterns
6. error-handling.md - Consistent error patterns
7. react-query-usage.md - Data fetching patterns

Impact: This review used your repository's specific code quality standards, security patterns, and best practices from the memory system (PRs #359, #360) - not just generic code review guidelines.

[jeremyeder]

Minimal=76mb / 211mb uncompressed
Full=217mb / 585mb uncompressed