ci: add release-candidate build workflow; harden GA latest tag#651
ci: add release-candidate build workflow; harden GA latest tag#651andyne13 wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughThis PR modifies the existing build.yml workflow so the ChangesDocker build/tag workflow changes
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
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/build_rc.yml (1)
34-34: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winAdd
persist-credentials: falseto checkout steps.The
actions/checkout@v4action persists theGITHUB_TOKENin.git/configby default. Since this workflow runs withpackages: writeand 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: falseAlso 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
📒 Files selected for processing (2)
.github/workflows/build.yml.github/workflows/build_rc.yml
| on: | ||
| push: | ||
| tags: ["v*-rc.*"] | ||
| workflow_dispatch: |
There was a problem hiding this comment.
🎯 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.
| 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`.
Adds the git-flow release-candidate image pipeline and removes a latent
latest-tagging fragility.build_rc.yml(new) — RC images offrelease/*:v*-rc.*tags; jobs guarded tobase_refstartingrefs/heads/release/.build.yml(api+admin-ui → ghcr + Docker Hub; ray → ghcr only).vX.Y.Z-rc.Nviatype=ref,event=tag; never tagslatest.build.yml: its jobs requirebase_ref==main, so an rc tag on a release branch is a no-op there, and vice-versa.build.yml(hardened) —latestwas gated onenable={{is_default_branch}}, which resolved true only whilemainwas the default branch. With the default branch nowdevelop, that expression could silently stop tagginglateston main-based GA releases. Since those jobs are already guarded tobase_ref==main, any tag reaching them is a GA release and should belatest— so it's now unconditional (type=raw,value=latest).Summary by CodeRabbit
New Features
v*-rc.*tags.latesttag is always applied for main image builds.Bug Fixes