[build] add renovate dependency workflow

[titusfortner]

🔗 Related Issues

Follow up to #17463

Also note that this process is entirely independent from the dashboard here: #13964
The dashboard is for seeing the current status not for creating new PRs

💥 What does this PR do?

Existing ci-renovate-rbe.yml keyed off branch name and PR title tags to run after a Renovate PR to use the bazel task to update pins since renovate doesn't know how to do that. Complicated when there are a ton of PRs being made and constantly in flux.

This PR replaces that approach (and Renovate controlled PRs in general) with this orchestrated, dispatch-triggered dependency workflow that produces only two stable PRs (renovate/minor, renovate/major).
Each run:

1. Use the rake update tasks to update things with bazel first to minimize duplicates
2. Runs Renovate against it for minor and major updates
3. Run rake pin tasks on renovate updates
4. Run RBE tests
5. Create / Update one of the 2 PRs only

🔧 Implementation Notes

• Not bothering with splitting between bindings, just run all update and all pin to catch everything
• PRs only update if all tests are passing; risks one failure preventing updates going forward, but we can address that later
• Splitting between major & minor assuming that minor/patch updates are less likely to require any code changes beyond the change

🤖 AI assistance

• No substantial AI assistance used
• AI assisted (complete below)
  • Tool(s):
  • What was generated:
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

• Manual dispatch only for now until I test it
• Independent of our Release Process which will still run the normal bazel update tasks

🔄 Types of changes

• New feature (non-breaking change which adds functionality and tests!)

[qodo-code-review]

Review Summary by Qodo

Replace Renovate workflow with orchestrated dependency update system

✨ Enhancement

Walkthroughs

Description

• Replace reactive Renovate PR approach with orchestrated dispatch workflow
• Produce two stable PRs (renovate/minor, renovate/major) instead of many
• Run bazel updates, Renovate, and pin tasks in coordinated sequence
• Only update PRs when all RBE tests pass

Diagram

flowchart LR
  A["Manual Dispatch"] --> B["Prepare Bazel Updates"]
  B --> C["Push Update Branch"]
  C --> D["Renovate Minor"]
  C --> E["Renovate Major"]
  D --> F["Evaluate & Pin Minor"]
  E --> G["Evaluate & Pin Major"]
  F --> H["Create/Update renovate/minor PR"]
  G --> I["Create/Update renovate/major PR"]

Loading

File Changes

1. .github/workflows/ci-renovate-rbe.yml ⚙️ Configuration changes +0/-79

Remove old reactive Renovate RBE workflow

• Deleted entire workflow file
• Removed reactive branch-based trigger approach
• Removed conditional language-specific pin tasks
• Removed sequential commit, format check, and test jobs

.github/workflows/ci-renovate-rbe.yml

---

2. .github/workflows/renovate-dependencies.yml ✨ Enhancement +123/-0

Add new orchestrated Renovate dependency workflow

• New orchestrated workflow triggered by manual dispatch
• Accepts configurable base branch reference input
• Runs bazel all:update and rust:update tasks first
• Pushes updates to temporary branch for Renovate processing
• Runs Renovate separately for minor and major updates with matrix strategy
• Calls renovate-dependency-pr.yml workflow for each update type
• Uses concurrency group to prevent parallel runs

.github/workflows/renovate-dependencies.yml

---

3. .github/workflows/renovate-dependency-pr.yml ✨ Enhancement +101/-0

Add workflow to evaluate and promote dependency updates

• New reusable workflow called by main Renovate workflow
• Detects if Renovate evaluation branch exists
• Runs bazel pin tasks and RBE tests on evaluation branch
• Commits pin changes back to evaluation branch
• Creates or updates stable PR from evaluation branch to base ref
• Includes comprehensive PR body with workflow documentation
• Validates kind input parameter is either minor or major

.github/workflows/renovate-dependency-pr.yml

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Patch base ref drift 🐞 Bug ☼ Reliability

Description

evaluate generates full-changes.patch by diffing against origin/${{ inputs.base-ref }}, but
promote checks out the moving ref ${{ inputs.base-ref }} later and applies the patch. If the
base branch advances between jobs (or base-ref is not a remote branch name), git apply can fail
and block dependency PR promotion.

Code

.github/workflows/renovate-dependency-pr.yml[R61-84]

+        git fetch origin "${{ inputs.base-ref }}" --depth=1
+        git add -A
+        git diff --binary --cached "origin/${{ inputs.base-ref }}" > full-changes.patch
+      artifact-name: ${{ inputs.kind }}-dependency-changes
+      artifact-path: full-changes.patch
+
+  promote:
+    name: Promote ${{ inputs.kind }} dependencies
+    needs: evaluate
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout base
+        uses: actions/checkout@v6
+        with:
+          ref: ${{ inputs.base-ref }}
+          persist-credentials: false
+      - name: Download patch
+        uses: actions/download-artifact@v8
+        with:
+          name: ${{ inputs.kind }}-dependency-changes
+      - name: Apply patch
+        run: |
+          git apply --index full-changes.patch
+          rm full-changes.patch

Evidence

The patch is generated relative to the remote-tracking ref origin/${{ inputs.base-ref }} during
evaluate, but promote later checks out ${{ inputs.base-ref }} again and applies that patch.
Since ${{ inputs.base-ref }} can advance between these jobs, the patch may no longer apply
cleanly, breaking promotion.

.github/workflows/renovate-dependency-pr.yml[61-63]
.github/workflows/renovate-dependency-pr.yml[72-84]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow creates a patch against `origin/${{ inputs.base-ref }}` in `evaluate`, but applies it after checking out `${{ inputs.base-ref }}` again in `promote`. Because `${{ inputs.base-ref }}` is typically a moving branch (e.g., `trunk`), the base can advance during the run, causing the patch to no longer apply cleanly and preventing the PR from being updated.

## Issue Context
This workflow intentionally promotes only a *passing* dependency set. That implies the patch should be applied to the *exact* base commit that was used when producing the patch.

## Fix Focus Areas
- .github/workflows/renovate-dependency-pr.yml[61-65]
- .github/workflows/renovate-dependency-pr.yml[72-84]

## Suggested fix approach
1. In `evaluate` (inside the `run:` script), after `git fetch origin "${{ inputs.base-ref }}" --depth=1`, capture the fetched base commit SHA (e.g., `BASE_SHA=$(git rev-parse FETCH_HEAD)`).
2. Generate the patch against that SHA (e.g., `git diff --binary --cached "$BASE_SHA" > full-changes.patch`).
3. Persist the SHA alongside the patch (e.g., write `base-sha.txt`) and upload both files as the artifact (use a multi-line `artifact-path`).
4. In `promote`, after downloading the artifact, check out the recorded SHA (or fetch+checkout it) before applying the patch, so the patch is applied to the exact base that was validated.
5. Remove any helper files (`base-sha.txt`, patch) before invoking `create-pull-request` to avoid committing them.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. git ls-remote origin without checkout ✓ Resolved 📘 Rule violation ☼ Reliability

Description

The detect-branch job runs git ls-remote ... origin ... without checking out the repository or
otherwise configuring an origin remote, so the step is likely to fail or produce an incorrect
exists output that prevents downstream evaluate/commit-pins/promote jobs from running even
when the target branch exists. This violates the requirement to harden CI/scripts so they behave
deterministically and robustly.

Code

.github/workflows/renovate-dependency-pr.yml[R40-44]

+          if git ls-remote --exit-code --heads origin "renovate/${KIND}-eval" >/dev/null; then
+            echo "exists=true" >> "$GITHUB_OUTPUT"
+          else
+            echo "exists=false" >> "$GITHUB_OUTPUT"
+          fi

Evidence

PR Compliance ID 15 requires CI/scripts to be hardened with safe, deterministic behavior, but in
detect-branch the workflow invokes git ls-remote ... origin on a fresh GitHub-hosted runner
without an actions/checkout step or remote setup, meaning origin is not configured and the
command can fail or incorrectly set exists=false. The contrast with other workflow usage where
actions/checkout precedes git ls-remote ... origin demonstrates the intended prerequisite and
highlights why this job’s current implementation is non-deterministic at runtime.

.github/workflows/renovate-dependency-pr.yml[40-44]
.github/workflows/renovate-dependency-pr.yml[25-44]
.github/workflows/renovate-dependencies.yml[69-79]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `detect-branch` job calls `git ls-remote ... origin ...` even though no repository checkout (or equivalent remote setup) occurs, so `origin` is undefined and the branch-existence detection becomes unreliable; this can incorrectly skip downstream `evaluate`/`commit-pins`/`promote` jobs.

## Issue Context
`detect-branch` runs on a fresh GitHub-hosted runner; without `actions/checkout`, there is no local git repository and no configured remote named `origin`, so `git ls-remote origin ...` can fail or yield incorrect results. Other jobs/workflows that successfully use `git ls-remote ... origin` do so after `actions/checkout`, which configures `origin`, indicating the missing prerequisite here.

## Fix Focus Areas
- .github/workflows/renovate-dependency-pr.yml[25-44]
- .github/workflows/renovate-dependency-pr.yml[40-44]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. gh api output quoting broken ✓ Resolved 📘 Rule violation ☼ Reliability

Description

In renovate-dependency-pr.yml, the detect-branch step uses nested, unescaped double-quotes
inside an echo "exists=$(...)" command substitution when writing to $GITHUB_OUTPUT, which can
break shell parsing and cause the workflow to fail before setting the exists output. Because
downstream evaluation/pinning/promotion is gated on steps.detect.outputs.exists, this can lead to
jobs being skipped or failing, violating the requirement to harden CI scripts with safe,
deterministic shell handling.

Code

.github/workflows/renovate-dependency-pr.yml[40]

+          echo "exists=$(gh api repos/${{ github.repository }}/branches/renovate/${{ inputs.kind }}-eval --silent && echo "true" || echo "false")" >> "$GITHUB_OUTPUT"

Evidence

PR Compliance ID 17 requires CI/scripts to avoid shell pitfalls and use safe argument/quoting
practices; the cited detect-branch output line embeds echo "true"/echo "false" inside an outer
double-quoted echo "exists=$(...)", which can terminate the outer string early and trigger a shell
syntax/quoting error so the output is never written to $GITHUB_OUTPUT. The workflow then relies on
needs.detect-branch.outputs.exists being set to 'true' to run the subsequent evaluate job, so
a failure to set this output directly prevents downstream jobs from running as intended.

.github/workflows/renovate-dependency-pr.yml[40-40]
.github/workflows/renovate-dependency-pr.yml[31-46]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `detect-branch` step writes `exists=...` to `$GITHUB_OUTPUT` using a command substitution containing nested, unescaped double-quotes (via `echo "true"` / `echo "false"` inside an outer `echo "exists=$(...)"`), which can break shell parsing and prevent the `exists` output from being set, causing downstream jobs gated on this value to skip or fail.

## Issue Context
This is part of a CI workflow and must be robust and deterministic (per PR Compliance ID 17) to avoid silent failures or broken runs. The problematic pattern is effectively `echo "exists=$( ... && echo "true" || echo "false")"`, where the inner quotes can prematurely terminate the outer string; downstream logic depends on `needs.detect-branch.outputs.exists` being `'true'` for the `evaluate` job (and related evaluation/pinning/promotion) to run.

## Fix Focus Areas
- .github/workflows/renovate-dependency-pr.yml[35-46]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View more (1)

4. Temp branch not ensured ✓ Resolved 🐞 Bug ☼ Reliability

Description

renovate-dependencies.yml always checks out temp/bazel-updates, but the reusable
commit-changes.yml workflow explicitly skips the push when changes.patch is missing/empty. When
the Bazel update step produces no diff (and bazel.yml deletes changes.patch), the temp branch
may not exist or may remain stale from a previous run, causing checkout failures or Renovate to run
on old content.

Code

.github/workflows/renovate-dependencies.yml[R36-62]

+  push-update-branch:
+    name: Push Bazel update branch
+    needs: prepare-updates
+    if: github.event.repository.fork == false
+    uses: ./.github/workflows/commit-changes.yml
+    with:
+      artifact-name: bazel-updates
+      commit-message: "Update dependencies"
+      ref: ${{ inputs.base-ref }}
+      push-branch: temp/bazel-updates
+    secrets:
+      SELENIUM_CI_TOKEN: ${{ secrets.SELENIUM_CI_TOKEN }}
+
+  renovate:
+    name: Renovate ${{ matrix.kind }} dependencies
+    needs: push-update-branch
+    if: github.event.repository.fork == false
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        kind: [minor, major]
+    steps:
+      - name: Checkout update branch
+        uses: actions/checkout@v6
+        with:
+          ref: temp/bazel-updates

Evidence

The Renovate job unconditionally checks out temp/bazel-updates, while the commit workflow will not
push anything when changes.patch is empty and bazel.yml removes empty patches, making the branch
potentially missing or stale.

.github/workflows/renovate-dependencies.yml[36-63]
.github/workflows/commit-changes.yml[46-56]
.github/workflows/bazel.yml[274-287]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow assumes `temp/bazel-updates` exists and reflects the current `base-ref`, but the branch is only pushed when `changes.patch` is non-empty. If there are no Bazel update changes, the branch is not pushed/created, yet the Renovate job still checks it out.

## Issue Context
- `bazel.yml` deletes `changes.patch` when empty.
- `commit-changes.yml` skips commit/push when `changes.patch` is empty.
- `renovate-dependencies.yml` always checks out `temp/bazel-updates`.

## Fix Focus Areas
- .github/workflows/renovate-dependencies.yml[36-63]
- .github/workflows/commit-changes.yml[46-56]
- .github/workflows/bazel.yml[274-287]

## Suggested fix
Ensure `temp/bazel-updates` is force-updated to the current `base-ref` even when there are no patch changes, for example:
- Update `commit-changes.yml` to still `git push --force origin HEAD:"$PUSH_BRANCH"` in the `else` branch (no patch), or
- Add a dedicated step/job in `renovate-dependencies.yml` that force-pushes `inputs.base-ref` to `temp/bazel-updates` when no patch is present, and gate the Renovate checkout accordingly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. Branch check hides git errors 🐞 Bug ☼ Reliability

Description

detect-branch treats any non-zero git ls-remote result as “branch does not exist”, so
auth/network/URL errors will set exists=false and silently skip evaluation/pinning/promotion. This
can lead to successful workflow runs that produce no dependency PR updates due to a false-negative
branch detection.

Code

.github/workflows/renovate-dependency-pr.yml[R35-41]

+          REPO_URL: ${{ github.server_url }}/${{ github.repository }}.git
+        run: |
+          case "$KIND" in
+            minor|major) ;;
+            *) echo "::error::kind must be minor or major"; exit 1 ;;
+          esac
+          if git ls-remote --exit-code --heads "$REPO_URL" "renovate/${KIND}-eval" >/dev/null; then

Evidence

The branch existence check uses git ls-remote and maps any failure to exists=false, and
downstream jobs are gated on that output; therefore, a non-branch-related git failure becomes a
silent skip of evaluation/promotion.

.github/workflows/renovate-dependency-pr.yml[33-45]
.github/workflows/renovate-dependency-pr.yml[47-51]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The `git ls-remote --exit-code` call is used to detect whether `renovate/${KIND}-eval` exists, but the current `if ...; then ... else ...` treats *all* failures the same. That conflates “no matching refs found” (exit code 2) with real errors (e.g., exit code 128), causing the workflow to silently skip downstream jobs.

### Issue Context
This output controls whether `evaluate` runs at all (`needs.detect-branch.outputs.exists == 'true'`). A false negative prevents pinning/tests and PR promotion.

### Fix Focus Areas
- .github/workflows/renovate-dependency-pr.yml[33-45]
- .github/workflows/renovate-dependency-pr.yml[47-51]

### Suggested fix
Capture the exit status from `git ls-remote` and:
- `0` => `exists=true`
- `2` => `exists=false`
- anything else => emit `::error::` and `exit 1` (or the same status)

Example shell pattern:
```bash
set +e
git ls-remote --exit-code --heads "$REPO_URL" "renovate/${KIND}-eval" >/dev/null 2>&1
status=$?
set -e

if [ "$status" -eq 0 ]; then
 echo "exists=true" >> "$GITHUB_OUTPUT"
elif [ "$status" -eq 2 ]; then
 echo "exists=false" >> "$GITHUB_OUTPUT"
else
 echo "::error::git ls-remote failed with exit code $status"
 exit "$status"
fi
```

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

6. Unvalidated base-ref input 🐞 Bug ☼ Reliability

Description

reset-update-branch checks out ${{ inputs.base-ref }} and then force-pushes a branch with write
credentials, but does not validate that base-ref is an expected/trusted branch/ref. A mistyped or
unexpected ref can run the workflow against unintended code/targets and update the wrong branches/PR
base.

Code

.github/workflows/renovate-dependencies.yml[R28-34]

+      - name: Checkout base ref
+        uses: actions/checkout@v6
+        with:
+          ref: ${{ inputs.base-ref }}
+          token: ${{ secrets.SELENIUM_CI_TOKEN || github.token }}
+      - name: Force-push to temp/bazel-updates
+        run: git push --force origin "HEAD:temp/bazel-updates"

Evidence

The job checks out the operator-provided inputs.base-ref and immediately force-pushes
temp/bazel-updates using a write-capable token, so the run’s behavior depends entirely on that
unchecked input.

.github/workflows/renovate-dependencies.yml[23-34]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow uses the free-form `base-ref` input directly for checkout and for updating branches, with write-capable credentials, without any guardrails.

## Issue Context
This is a manual `workflow_dispatch`, so operator mistakes (or choosing an unexpected ref like pull refs) can cause the workflow to operate on unintended code and update branches/PR base incorrectly.

## Fix Focus Areas
- .github/workflows/renovate-dependencies.yml[23-35]

## Suggested fix
Add a validation step early in the workflow to restrict `base-ref` to allowed patterns/branches (e.g., `trunk`, release branches) and/or explicitly reject `refs/pull/*` and other unexpected refs; fail fast with a clear error message if validation fails.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

7. PR promotion token missing ✓ Resolved 🐞 Bug ☼ Reliability

Description

renovate-dependency-pr.yml declares SELENIUM_CI_TOKEN as optional but passes it as the token
for peter-evans/create-pull-request@v8 without fallback, which can cause promotion to fail
authentication when the secret isn’t set/passed. This is inconsistent with other workflows in the
repo that already use secrets.SELENIUM_CI_TOKEN || github.token for safe fallback.

Code

.github/workflows/renovate-dependency-pr.yml[R78-83]

+      - name: Create or update PR
+        uses: peter-evans/create-pull-request@v8
+        with:
+          token: ${{ secrets.SELENIUM_CI_TOKEN }}
+          branch: renovate/${{ inputs.kind }}
+          base: ${{ inputs.base-ref }}

Evidence

The workflow-call secret is explicitly optional, but the PR creation step uses it without fallback;
other workflows in the same repo demonstrate the intended fallback pattern.

.github/workflows/renovate-dependency-pr.yml[14-17]
.github/workflows/renovate-dependency-pr.yml[78-83]
.github/workflows/renovate-dependencies.yml[101-105]
.github/workflows/commit-changes.yml[36-41]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The promote step uses `${{ secrets.SELENIUM_CI_TOKEN }}` directly even though the secret is declared `required: false`, so the token may be empty and PR creation will fail.

## Issue Context
Other workflows (including this PR’s `renovate` job and the reusable `commit-changes.yml`) already use a `|| github.token` fallback.

## Fix Focus Areas
- .github/workflows/renovate-dependency-pr.yml[14-17]
- .github/workflows/renovate-dependency-pr.yml[78-83]

## Suggested fix
Either:
- Change to `token: ${{ secrets.SELENIUM_CI_TOKEN || github.token }}` in the `create-pull-request` step, or
- Mark `SELENIUM_CI_TOKEN` as `required: true` if fallback is not acceptable.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[Copilot]

Pull request overview

Introduces a new manually-dispatched dependency update pipeline that stages Bazel-driven updates, runs Renovate for minor/major updates, repins dependencies, validates via RBE, and then maintains two stable PRs (renovate/minor, renovate/major) instead of many per-dependency PRs.

Changes:

• Add a workflow_dispatch-triggered orchestration workflow to run Bazel update tasks, run Renovate (minor+major), and then kick off PR promotion.
• Add a reusable workflow that repins + tests an eval branch and then creates/updates the stable dependency PR.
• Remove the legacy ci-renovate-rbe.yml workflow that depended on branch naming/title tags.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
.github/workflows/renovate-dependency-pr.yml	New reusable workflow to validate/pin an eval branch and promote it into a stable dependency PR.
.github/workflows/renovate-dependencies.yml	New dispatch workflow that prepares a temp update branch, runs Renovate for minor/major, and triggers promotion.
.github/workflows/ci-renovate-rbe.yml	Removes the previous renovate-branch-driven pin/test workflow.

[qodo-code-review]

Persistent review updated to latest commit 7b88946

[qodo-code-review]

Persistent review updated to latest commit fbe66c1

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

[qodo-code-review]

Persistent review updated to latest commit 7895f48

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

[qodo-code-review]

Persistent review updated to latest commit d644e2d

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.