Enhance Container Build Flow for Unified Release & SBOM Handling #108
Description
Summary
Propose consolidating our container build flow to handle all image build and release scenarios, including production releases, with SBOM (Software Bill of Materials) and provenance support.
Background
- Currently, our release builds and regular dev/PR builds are handled in separate workflows (release.yml and build.yml, plus container-build-flow-action for CI).
- This split causes duplication of build steps, inconsistent SBOM strategies, and higher maintenance overhead.
Proposal
- Update or extend the container build flow so it can also handle official release builds (when a release is published or a production tag is created).
- Move all SBOM generation and provenance logic into the container build flow, making it SOLELY responsible for container image attestation for ALL scenarios (dev, PR, staging, release).
- Centralize multi-arch build support, semantic versioning/tagging for releases, Docker Buildx configurations, and registry handling in the action.
- This will reduce workflow duplication, streamline maintenance, and make our supply chain security more robust and DRY.
Key Considerations
- Workflow triggers (must work for PRs, dev/main, AND release events)
- SBOM & provenance: produced by container-build-flow-action only
- Semantic version docker tag logic for releases
- Multi-arch builds for production releases
- Community or marketplace users may benefit from a generalized solution
Impact
- Easier workflow maintenance
- Consistent SBOM/provenance generation
- One place for all container-related build improvements and security
- Simplified onboarding and iteration
Related to internal discussions and feedback from PR #104 and current workflow audit.