Incorporate sbom/provenance for docker image build/push pipeline

[Iznogohul]

Description

Prior to this commit, Docker images were built manually via raw CLI commands in the workflow, and several GitHub Actions dependencies relied on mutable version tags.This PR transitions some Docker build pipeline to use official, Docker actions. Additionally, third-party and newly introduced action references have been pinned to exact commit SHAs to guarantee immutable, reproducible, and more secure CI runs.

Added

• The ability to generate SBOM and max-level provenance records for each docker image push into dockerhub

Changed

• Transition the build process to official docker/build-push-action and metadata-action steps.
• Replaced manual Docker tag generation with docker/metadata-action to centralize image tagging.

Fixed

• Secure the CI workflow by pinning third-party and new actions to exact commit SHAs.

Notes:

• Not sure if Check core size is still relevant as a step because if the current runs fails silently, in the pr is not present
• Max provenance exposes all the build arg secrets that a docker image might use
• Might worth investigating https://docs.docker.com/build/cache/backends/gha/
• Tarball artifacts are being upload on the same name BlueOS-core-docker-images-${{ env.GIT_HASH_SHORT }} as a zip,

Summary by Sourcery

Modernize the Docker image build and release workflow by switching to official Docker actions for building, tagging, and pushing images, adding SBOM and provenance generation, consolidating multi-architecture core image artifacts, and hardening CI by pinning action versions.

New Features:

• Generate SBOM and max-level provenance metadata for Docker image builds in the test-and-deploy workflow.
• Produce standalone release tarball artifacts for core Docker images across multiple architectures in a single aggregated artifact.

Bug Fixes:

• Pin Docker and artifact-related GitHub Actions to immutable commit SHAs to improve CI security and reproducibility.

Enhancements:

• Adopt official docker/metadata-action for centralized image tag generation based on branches, tags, and semver.
• Replace manual buildx CLI invocations with docker/build-push-action for both build-only and build-and-push steps, including cache configuration and build arguments.
• Streamline artifact creation by building multi-architecture core images in a loop and uploading them under a single, version-specific artifact name.
• Narrow release upload globbing to core image tarballs to avoid unintentionally matching other artifacts.

CI:

• Refine the test-and-deploy workflow to use maintained Docker actions and updated upload-artifact configuration while removing the unused core image size check step.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sourcery-ai]

Hey - I've left some high level feedback:

• The images input for docker/metadata-action uses ${{ env.DOCKER_USERNAME || 'bluerobotics' }}, but GitHub expressions don’t support || directly; consider restructuring this to a supported conditional expression (e.g. using a separate env or if block) so the default username behavior works as intended.
• In the standalone tarball step, you start three docker buildx build processes in the background all sharing the same local cache (cache-to/cache-from); this parallel use of the same cache directory can lead to race conditions or corruption, so consider serializing these builds or using distinct cache scopes/paths per platform.
• Enabling provenance: mode=max alongside build args may unintentionally expose sensitive build-time values in the attestation, so it’s worth explicitly reviewing which build args may carry secrets and adjusting provenance mode or build arg usage to avoid leaking sensitive data.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `images` input for `docker/metadata-action` uses `${{ env.DOCKER_USERNAME || 'bluerobotics' }}`, but GitHub expressions don’t support `||` directly; consider restructuring this to a supported conditional expression (e.g. using a separate `env` or `if` block) so the default username behavior works as intended.
- In the standalone tarball step, you start three `docker buildx build` processes in the background all sharing the same local cache (`cache-to`/`cache-from`); this parallel use of the same cache directory can lead to race conditions or corruption, so consider serializing these builds or using distinct cache scopes/paths per platform.
- Enabling `provenance: mode=max` alongside build args may unintentionally expose sensitive build-time values in the attestation, so it’s worth explicitly reviewing which build args may carry secrets and adjusting provenance mode or build arg usage to avoid leaking sensitive data.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}