Consolidate Docker publishing into build-and-test workflow

[t0mdavid-m]

Summary

Removes the standalone publish-docker-images.yml workflow and consolidates Docker image building and publishing into the build-and-test.yml workflow. This simplifies the CI/CD pipeline by eliminating a separate workflow file and ensuring Docker images are only published after passing integration tests (apptainer, nginx, traefik).

Key Changes

• Removed .github/workflows/publish-docker-images.yml — standalone workflow that built and published Docker images to GHCR
• Modified .github/workflows/build-and-test.yml:
  • Changed trigger from tags: ['v*'] to workflow_call to allow invocation from other workflows
  • Updated latest-amd64 and latest-arm64 tag conditions to enable on both release events and develop branch pushes
  • Added RELEASE_TAG build argument (passed on release events) to pin Docker image builds to the specific release being published
  • Updated create-manifest job to depend on integration test jobs (test-apptainer, test-nginx, test-traefik), ensuring multi-arch manifests are only created after tests pass
  • Updated manifest tag conditions to match per-arch tag logic (enable on release or develop push)
• Modified .github/workflows/build-windows-executable-app.yaml:
  • Added new publish-web-image job that triggers build-and-test.yml as a reusable workflow on release events
  • This ensures Docker images are built and published only after the Windows installer is uploaded as a release asset
• Modified Dockerfile and Dockerfile.arm:
  • Added RELEASE_TAG build argument
  • Updated release asset download logic to use the specific release tag when provided, falling back to latest release when empty
  • Preserves backward compatibility for develop/manual builds

Implementation Details

The new flow for releases:

1. Release is published → build-windows-executable-app.yaml builds and uploads Windows installer
2. Windows build completes → publish-web-image job calls build-and-test.yml with RELEASE_TAG set
3. build-and-test.yml builds Docker images with the matching release tag, runs integration tests
4. Only after tests pass, multi-arch manifests are created and pushed to GHCR

This ensures the Docker images bundled with a release contain the exact matching Windows installer, and that all images pass integration tests before being promoted to :latest tags.

https://claude.ai/code/session_011vfx32E4R7HTs19TtHZps9

Summary by CodeRabbit

• Chores
  • Consolidated Docker image release workflows for improved release management.
  • Enhanced Docker builds to support pinned release versions.
  • Strengthened CI/CD pipeline with expanded testing requirements before publishing multi-architecture images.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 0f7fb12d-52db-45e7-95c8-49e6aee9633f

📥 Commits

Reviewing files that changed from the base of the PR and between 689b031 and ada985b.

📒 Files selected for processing (5)

• .github/workflows/build-and-test.yml
• .github/workflows/build-windows-executable-app.yaml
• .github/workflows/publish-docker-images.yml
• Dockerfile
• Dockerfile.arm

💤 Files with no reviewable changes (1)

• .github/workflows/publish-docker-images.yml

---

📝 Walkthrough

Walkthrough

The PR consolidates Docker image publishing from a dedicated publish-docker-images.yml workflow into the reusable build-and-test.yml workflow, adds release tag pinning support for reproducible builds, and extends release event handling across image tagging and publishing gates.

Changes

Release-pinned Docker publishing consolidation

Layer / File(s)	Summary
Workflow consolidation and reusability .github/workflows/build-and-test.yml, .github/workflows/build-windows-executable-app.yaml	build-and-test.yml is made reusable via workflow_call trigger, and a new publish-web-image job in the Windows executable workflow invokes it on release events to consolidate multi-arch publishing.
AMD64 image with release tag support .github/workflows/build-and-test.yml	build-amd64 job now tags images as "latest" on release events and passes RELEASE_TAG build argument derived from the release tag name.
ARM64 image with release tag support .github/workflows/build-and-test.yml	build-arm64 job now tags images as "latest" on release events and passes RELEASE_TAG build argument derived from the release tag name.
Multi-arch manifest publishing gate .github/workflows/build-and-test.yml	create-manifest job now requires integration tests (test-apptainer, test-nginx, test-traefik) to complete before creating multi-arch manifests, and "latest" tag condition includes release events.
Apptainer release event tagging .github/workflows/build-and-test.yml	publish-apptainer job's "latest" tag condition is updated to include release events.
Dockerfile release tag download logic Dockerfile, Dockerfile.arm	Both Dockerfiles introduce RELEASE_TAG build argument and use gh release download with the specified tag when provided; otherwise download the latest release.

Sequence Diagram

sequenceDiagram
  participant Release as GitHub Release
  participant WindowsWorkflow as Windows Executable<br/>Workflow
  participant BuildTestWorkflow as Build & Test<br/>Workflow (reusable)
  participant DockerBuild as Docker Build<br/>(AMD64/ARM64)
  participant Registry as GHCR Registry
  participant Integration as Integration Tests<br/>(apptainer/nginx/traefik)
  
  Release->>WindowsWorkflow: trigger on release event
  WindowsWorkflow->>WindowsWorkflow: build-executable
  WindowsWorkflow->>BuildTestWorkflow: invoke via workflow_call
  BuildTestWorkflow->>DockerBuild: build-amd64 (with RELEASE_TAG)
  BuildTestWorkflow->>DockerBuild: build-arm64 (with RELEASE_TAG)
  DockerBuild->>Registry: push amd64/arm64 images<br/>tagged as "latest"
  BuildTestWorkflow->>Integration: run test-apptainer,<br/>test-nginx, test-traefik
  Integration-->>BuildTestWorkflow: pass
  BuildTestWorkflow->>Registry: create-manifest<br/>(multi-arch, "latest" tag)

Loading

Possibly Related PRs

• OpenMS/FLASHApp#64: Introduces ARM64 Dockerfile.arm image and CI job; this PR extends that infrastructure with RELEASE_TAG-driven pinned releases.
• OpenMS/FLASHApp#72: Modifies the same build-and-test.yml multi-arch pipeline and extends Docker build inputs via RELEASE_TAG.
• OpenMS/FLASHApp#65: Modifies Dockerfile and Dockerfile.arm download logic for OpenMS-App.zip via gh release download.

Poem

🐰 Hops with glee, a workflow's refactored dance,
Release tags pinned with GHCR's advance,
AMD64 and ARM64, in manifest they blend,
Docker images consolidated, from start to end!
Multi-arch gates now guard the way—
A cleaner publishing pipeline, hooray! 🎉

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title 'Consolidate Docker publishing into build-and-test workflow' directly and clearly summarizes the main objective: removing the standalone publish-docker-images workflow and merging its functionality into the build-and-test workflow.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/fervent-gauss-GWwNx

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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