feat: docker-build-push

[marek-saji]

Why?

Closes https://verkstedt.atlassian.net/browse/VIP-48

What?

Workflow that is triggered when new version tag or anything to main is pushed. It will build a docker image and depending on vars set in the repo (or org), will push it to different registries (GitHub Container Registry, Google Artifact Registry, Amazon ECR).

Review notes

Important

Remember this is a public repo. Do not discuss internal projects.

• Pushing to Amazon has NOT been tested.
• Vars can be seen at https://github.com/verkstedt/actions--test/settings/variables/actions

Testing

There’s a private test repo set up at https://github.com/verkstedt/actions--test it sends notifications to #infrastructure-create-release-pr-action slack channel.

TODO before this is merged

• Replace all @feat/docker-build-push with @v1

TODO after this is merged

• Add workflow template to verkstedt/.github repo. Will look something like https://github.com/verkstedt/actions--test/blob/main/.github/workflows/docker-build-push.yaml
• Stop using reusable-tag-docker-release-images and reusable-release workflows and remove them
• https://verkstedt.atlassian.net/browse/RDC999-406

[coderabbitai]

Note

Reviews paused

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

📝 Walkthrough

Summary by CodeRabbit

• New Features

  • Added a GitHub Actions workflow for building and pushing Docker images to multiple registries with support for multi-platform builds, semantic versioning, and dry-run mode.
  • Includes automated Slack notifications for deployment completion.

• Documentation

  • Added documentation for the new Docker Build and Push workflow template.

Walkthrough

Adds a reusable GitHub Actions workflow that builds and pushes multi-architecture Docker images to GHCR, Google Artifact Registry, and Amazon ECR with computed tags (git-SHA, edge, semantic versions, latest), optional dry-run, caching, and Slack success notification; also adds README documentation referencing the workflow.

Changes

Cohort / File(s)	Summary
Docker Build & Push workflow ​.github/workflows/docker-build-push.yaml	New workflow_call that verifies enabled registries, computes platforms and tags (git-<short_sha>, edge, semantic version subsets, latest when appropriate), authenticates to GHCR/GAR/ECR as configured, sets up QEMU/Buildx, runs docker/build-push with caching and provenance, supports dry-run, and optionally notifies Slack on successful pushes.
Documentation README.md	Adds a workflow template entry describing the Docker Build and Push workflow, its purpose, inputs/secrets, tagging behavior, and link to the workflow file.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor Caller as Caller (workflow_call / Manual)
  participant Runner as GitHub Actions Runner
  participant GHCR as GHCR
  participant GAR as Google Artifact Registry
  participant ECR as Amazon ECR
  participant Slack as Slack

  Caller->>Runner: invoke workflow with inputs & secrets
  Runner->>Runner: ensure >=1 registry enabled
  Runner->>Runner: derive platforms & compute tags
  Runner->>Runner: setup QEMU & Buildx
  alt GHCR enabled
    Runner->>GHCR: authenticate (docker/login)
  end
  alt GAR enabled
    Runner->>GAR: auth (WIF/service account) & docker/login
  end
  alt ECR enabled
    Runner->>ECR: assume role / set creds & docker/login
  end
  Runner->>Runner: docker/build-push (context, dockerfile, platforms, tags, cache, dry-run)
  par Push to enabled registries
    Runner->>GHCR: push images
    Runner->>GAR: push images
    Runner->>ECR: push images
  end
  opt Success & contains "latest" & not dry-run
    Runner->>Slack: send success notification
  end
  note over Runner: publish step summary with platforms, tags, registries

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Areas to pay extra attention:

• Tag-generation logic (edge vs main, semantic version parsing and prerelease handling).
• Authentication blocks for Google (WIF/service account) and AWS (assume-role) correctness.
• Buildx/QEMU setup and docker/build-push arguments (platforms, caching, dry-run behavior).
• Slack notification conditional and secrets usage.

Possibly related PRs

• Change “latest” docker image tags #21 — Overlaps in image tag computation and tagging policy (edge/latest/version handling).

Suggested reviewers

• erolci

Poem

I stirred the pots where dockers brew,
Tagged the waves with git and hue;
Edge leaps in when main is seen,
Versions parade in tidy sheen.
I press "push" with thumping paws—then Slack lights up for all to view. 🐇⛵️

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'feat: docker-build-push' directly describes the main feature being added, matching the changeset which introduces a new Docker build and push workflow.
Linked Issues check	✅ Passed	The changeset implements all core requirements from VIP-48: triggers on version tags and main pushes, builds Docker images, supports authentication and pushing to multiple registries (GitHub, Google, AWS) with configurable variables, includes tagging strategy with git-SHA and semantic versions.
Out of Scope Changes check	✅ Passed	All changes are in scope: the docker-build-push.yaml workflow directly implements VIP-48 requirements, and README.md documentation addition documents the new workflow template.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	The pull request description clearly relates to the changeset by explaining the purpose (GitHub Actions workflow for Docker builds and pushes), the specific implementation details (triggering on version tags and main branch pushes, multi-registry support), and relevant context for reviewers.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[stepahn]

looks good to me, I'll give the registry actions a try and see if I can adopt those in TIH though I'm not sure if I can use the whole docker-build-push action though

Maybe at least the docker-setup-registry/*.

yeah, the registry actions I'm gonna try … and with the recent additions I can try and see if I could use the whole aciton