Skip to content

ci: add release-candidate build workflow; harden GA latest tag#651

Open
andyne13 wants to merge 1 commit into
developfrom
feature/rc-build-workflow
Open

ci: add release-candidate build workflow; harden GA latest tag#651
andyne13 wants to merge 1 commit into
developfrom
feature/rc-build-workflow

Conversation

@andyne13

@andyne13 andyne13 commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Adds the git-flow release-candidate image pipeline and removes a latent latest-tagging fragility.

build_rc.yml (new) — RC images off release/*:

  • Triggers on v*-rc.* tags; jobs guarded to base_ref starting refs/heads/release/.
  • Builds all 3 images (api, ray, admin-ui), same registry split as build.yml (api+admin-ui → ghcr + Docker Hub; ray → ghcr only).
  • Tag = vX.Y.Z-rc.N via type=ref,event=tag; never tags latest.
  • No overlap with build.yml: its jobs require base_ref==main, so an rc tag on a release branch is a no-op there, and vice-versa.

build.yml (hardened)latest was gated on enable={{is_default_branch}}, which resolved true only while main was the default branch. With the default branch now develop, that expression could silently stop tagging latest on main-based GA releases. Since those jobs are already guarded to base_ref==main, any tag reaching them is a GA release and should be latest — so it's now unconditional (type=raw,value=latest).

Summary by CodeRabbit

  • New Features

    • Added a new release-candidate build workflow that publishes API, Ray, and Admin UI container images for v*-rc.* tags.
    • Updated image tagging so the latest tag is always applied for main image builds.
  • Bug Fixes

    • Improved release image publishing behavior by aligning tags with release-candidate and main build flows.

@coderabbitai

coderabbitai Bot commented Jul 8, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

This PR modifies the existing build.yml workflow so the latest Docker tag is always applied regardless of branch, and adds a new build_rc.yml workflow that builds and pushes API, Ray, and Admin UI images to GHCR and Docker Hub when release-candidate tags matching v*-rc.* are pushed from release/* branches.

Changes

Docker build/tag workflow changes

Layer / File(s) Summary
Unconditional latest tag
.github/workflows/build.yml
The latest raw tag is now always added via docker/metadata-action for the API, Ray, and Admin UI image jobs, instead of being conditional on the default branch.
New Build RC workflow
.github/workflows/build_rc.yml
New workflow triggered by v*-rc.* tag pushes with a release/* base-ref check, defining shared registry/image env vars and three independent jobs that build and push API, Ray, and Admin UI images to GHCR (and Docker Hub for API/Admin UI) using docker/metadata-action and docker/build-push-action.

Estimated code review effort: 2 (Simple) | ~10 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Tag as v*-rc.* tag push
  participant GHA as GitHub Actions
  participant GHCR as GHCR Registry
  participant DockerHub as Docker Hub

  Tag->>GHA: trigger Build RC workflow
  GHA->>GHA: verify base_ref is release/*
  GHA->>GHCR: login and push API image
  GHA->>DockerHub: login and push API image
  GHA->>GHCR: login and push Ray image
  GHA->>GHCR: login and push Admin UI image
  GHA->>DockerHub: login and push Admin UI image
Loading

Possibly related PRs

  • linagora/openrag#593: Both PRs modify the same .github/workflows/build_rc.yml workflow for controlling RC image builds/tagging.
  • linagora/openrag#595: Both PRs touch .github/workflows/build_rc.yml, with the retrieved PR later restructuring the workflow this PR introduces.
  • linagora/openrag#648: Both PRs modify build.yml's docker/metadata-action tag generation, including Admin UI latest tagging logic.

Suggested labels: chore

Suggested reviewers: Ahmath-Gadji, hedhoud

🚥 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 title clearly summarizes the two main CI changes: adding the RC workflow and hardening latest tagging.
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.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feature/rc-build-workflow

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

Comment @coderabbitai help to get the list of available commands.

@andyne13 andyne13 marked this pull request as ready for review July 8, 2026 23:24
@coderabbitai coderabbitai Bot added the chore No production code impact, typically improve tooling, code quality, etc label Jul 8, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🧹 Nitpick comments (1)
.github/workflows/build_rc.yml (1)

34-34: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win

Add persist-credentials: false to checkout steps.

The actions/checkout@v4 action persists the GITHUB_TOKEN in .git/config by default. Since this workflow runs with packages: write and has Docker Hub credentials in the environment, disabling credential persistence reduces the attack surface for credential exfiltration via cache artifacts or build context.

🛡️ Proposed fix (apply to all three checkout steps)
       - uses: actions/checkout@v4
+        with:
+          persist-credentials: false

Also applies to: 85-85, 128-128

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/build_rc.yml at line 34, The checkout steps in the
workflow are persisting the GitHub token by default, which should be disabled
for all uses of actions/checkout@v4. Update each checkout step in this workflow
to set persist-credentials to false, including the ones in the build_rc job and
the other checkout occurrences referenced by the review, so no credentials are
written into .git/config during later build or cache steps.

Source: Linters/SAST tools

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/build_rc.yml:
- Around line 16-19: The `workflow_dispatch` trigger in `build_rc.yml` is
ineffective because the job guards in all three jobs still only allow
`startsWith(github.ref, 'refs/tags/')`. Either remove `workflow_dispatch` from
the workflow trigger if manual runs are not needed, or update each job’s `if`
condition to also allow manual dispatches so the jobs in the workflow actually
execute when run via `workflow_dispatch`.

---

Nitpick comments:
In @.github/workflows/build_rc.yml:
- Line 34: The checkout steps in the workflow are persisting the GitHub token by
default, which should be disabled for all uses of actions/checkout@v4. Update
each checkout step in this workflow to set persist-credentials to false,
including the ones in the build_rc job and the other checkout occurrences
referenced by the review, so no credentials are written into .git/config during
later build or cache steps.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: b8495541-7390-4a1b-9eff-c0e161b7f6cf

📥 Commits

Reviewing files that changed from the base of the PR and between 760531e and 368db80.

📒 Files selected for processing (2)
  • .github/workflows/build.yml
  • .github/workflows/build_rc.yml

Comment on lines +16 to +19
on:
push:
tags: ["v*-rc.*"]
workflow_dispatch:

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

workflow_dispatch trigger is effectively dead.

When manually dispatched, github.ref is refs/heads/<branch> (not refs/tags/...) and github.event.base_ref is unset, so every job's if condition (startsWith(github.ref, 'refs/tags/')) evaluates to false and all jobs are skipped. Either remove workflow_dispatch if manual triggering isn't needed, or relax the guard to accommodate it.

🔧 Option A: Remove workflow_dispatch
 on:
   push:
     tags: ["v*-rc.*"]
-  workflow_dispatch:
🔧 Option B: Allow workflow_dispatch in job guards
     if: |
-      startsWith(github.ref, 'refs/tags/') && startsWith(github.event.base_ref, 'refs/heads/release/')
+      (github.event_name == 'workflow_dispatch') ||
+      (startsWith(github.ref, 'refs/tags/') && startsWith(github.event.base_ref, 'refs/heads/release/'))

Apply to all three jobs (lines 28, 79, 122).

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
on:
push:
tags: ["v*-rc.*"]
workflow_dispatch:
on:
push:
tags: ["v*-rc.*"]
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/build_rc.yml around lines 16 - 19, The `workflow_dispatch`
trigger in `build_rc.yml` is ineffective because the job guards in all three
jobs still only allow `startsWith(github.ref, 'refs/tags/')`. Either remove
`workflow_dispatch` from the workflow trigger if manual runs are not needed, or
update each job’s `if` condition to also allow manual dispatches so the jobs in
the workflow actually execute when run via `workflow_dispatch`.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

chore No production code impact, typically improve tooling, code quality, etc

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant