Skip to content

Multi-platform container builds via job queue#982

Closed
pditommaso wants to merge 4 commits intomasterfrom
multi-platform
Closed

Multi-platform container builds via job queue#982
pditommaso wants to merge 4 commits intomasterfrom
multi-platform

Conversation

@pditommaso
Copy link
Collaborator

Summary

  • Adds application-level multi-platform build orchestration: a single build request fans out two single-platform builds (linux/amd64 + linux/arm64), then assembles an OCI Image Index (manifest list) pointing at both platform images
  • Integrates with the existing JobManager/JobHandler infrastructure (MultiBuild job type) instead of raw CompletableFuture threads, gaining consistent monitoring, timeout handling, and cleanup
  • New ManifestAssembler creates and pushes OCI manifest lists using the registry HTTP API directly
  • Multi-platform flag (multiPlatform boolean) on BuildRequest, ScanRequest and ScanEntry survives all serialization boundaries (Moshi/Redis), ensuring correct platform display (linux/amd64,linux/arm64) across build history, scan pages, and email notifications

New files

  • MultiPlatformBuildService — orchestrator, implements JobHandler<MultiBuildEntry>
  • MultiBuildRequest / MultiBuildEntry / MultiBuildStateStore — state model for multi-build jobs
  • ManifestAssembler — creates & pushes OCI Image Index via registry API
  • MultiContainerPlatformContainerPlatform subclass for composite platform display

Key design decisions

  • Sub-builds suppress individual scan and email (scanId=null, noEmail=true); scan and notification run once on the composite image
  • MultiBuild jobs skip pendingQueue (no K8s resources) and go directly to processingQueue
  • Status polling derives from sub-build entries in BuildStateStore

Test plan

  • MultiPlatformBuildServiceTest — job completion, failure, timeout, exception
  • MultiBuildRequestTest / MultiBuildEntryTest — state model
  • ManifestAssemblerTest — manifest list construction
  • ContainerScanServiceImplTest / ScanEntryTest / WaveScanRecordTest
  • E2E: submit multi-platform build via wave-cli, verify manifest list and status polling

🤖 Generated with Claude Code

Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>

def 'should fail to extract platform from unknown image name'() {
when:
ManifestAssembler.extractPlatform([:], 'repo:some-tag')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

extractPlatform does not exist

Refactor ContainerPlatform to support multi-arch builds natively,
replacing MultiContainerPlatform with a unified model. Fan out security
scans per architecture since Trivy only accepts a single --platform flag.

Key changes:
- Consolidate ContainerPlatform to handle both single and multi-arch
- Add ScanIds helper for encoding/decoding per-platform scan IDs
- Fan out scans in ContainerScanServiceImpl per architecture
- Add BuildRequest.withScanId() for propagating multi-scan IDs
- Update views and email templates for per-arch scan links
- Poll all per-arch scans in ContainerStatusServiceImpl
- Extract ScanIds.populateScanBinding() to DRY scan binding logic

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@pditommaso
Copy link
Collaborator Author

Alternative implementation #985

@pditommaso
Copy link
Collaborator Author

Closing in favour of #985

@pditommaso pditommaso closed this Mar 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants