[build] fix when to update lock files during the release process

[titusfortner]

We've removed and added when to run update command after running version commands. The issue is that in pre-release we do not want to update just because version has updated, but for the release and bumping nightly we do.

Ruby and Rust are the two that are affected by this. This fixes the same way for both.

💥 What does this PR do?

• Update is only needed in release workflow not in the rake task

🤖 AI assistance

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

💡 Additional Considerations

Probably should also update the local release process, but that's low priority

🔄 Types of changes

• Bug fix (backwards compatible)

[qodo-code-review]

Review Summary by Qodo

Separate lock file updates from version updates in release workflow

🐞 Bug fix

Walkthroughs

Description

• Remove automatic lock file updates from Rust version task
• Add dedicated workflow jobs for updating dependencies after release
• Separate version updates from lock file updates in release process
• Update workflow dependencies to include new lock file update jobs

Diagram

flowchart LR
  A["Rust Version Task"] -->|removed invoke| B["Rust Update Task"]
  C["Release Workflow"] --> D["Update Version"]
  D --> E["Reset Dependencies Job"]
  E --> F["Commit Dependencies Job"]
  F --> G["Nightly Job"]
  H["Failure Handler"] -->|now depends on| F

Loading

File Changes

1. rake_tasks/rust.rake 🐞 Bug fix +0/-6

Remove automatic lock file update from version task

• Removed automatic invocation of rust:update task from the rust:version task
• Removed reenable logic that was used to refresh Cargo.lock on repeated invocations
• Lock file updates are now handled separately in the release workflow

rake_tasks/rust.rake

---

2. .github/workflows/release.yml ✨ Enhancement +25/-2

Add dedicated workflow jobs for lock file updates

• Added new reset-dependencies job to update lock files after version updates
• Added new commit-dependencies job to commit updated lock files
• Updated nightly job dependency from update-version to commit-dependencies
• Updated on-release-failure job to depend on new lock file update jobs
• Added lock file update status to failure notification message

.github/workflows/release.yml

---

[qodo-code-review]

Code Review by Qodo

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

1. Nightly updates full deps 🐞 Bug ≡ Correctness

Description

The new reset-dependencies job runs ./go <language>:update based on the released language, but
several :update tasks perform full dependency upgrades (not just lockfile refresh) and the
workflow then commits those changes to trunk. This can push large, unintended dependency version
bumps (e.g., Maven/pnpm/paket/bundler updates) as part of the nightly reset process.

Code

.github/workflows/release.yml[R275-283]

+  reset-dependencies:
+    name: Update Lockfiles for Nightly
+    needs: [parse-tag, update-version]
+    uses: ./.github/workflows/bazel.yml
+    with:
+      name: Reset Dependencies
+      run: ./go ${{ needs.parse-tag.outputs.language }}:update${{ needs.parse-tag.outputs.language == 'all' && ' && ./go rust:update' || '' }}
+      artifact-name: version-reset-deps
+

Evidence

release.yml now runs ${language}:update and commits its output; parse-release-tag.yml shows
${language} can be java/dotnet/javascript/python/ruby/all. In the repo, multiple :update tasks
clearly perform dependency upgrades (e.g., Java rewrites MODULE.bazel using @maven//:outdated,
Ruby executes bundle update, Node executes pnpm update, .NET runs paket-update, Python updates
pinned requirements), so the workflow will commit more than a lockfile refresh.

.github/workflows/release.yml[253-306]
.github/workflows/parse-release-tag.yml[39-73]
rake_tasks/java.rake[281-307]
rake_tasks/node.rake[47-55]
rake_tasks/dotnet.rake[105-109]
rake_tasks/python.rake[127-137]
rake_tasks/ruby.rake[220-226]
rb/support/bundle_update.rb[20-39]

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 release workflow’s new `reset-dependencies` job executes `${language}:update`, but `:update` is implemented as a dependency upgrade in multiple languages (Java uses `@maven//:outdated`, Node runs `pnpm update`, Ruby runs `bundle update`, etc.). The workflow then commits these changes with a “lockfiles” message, which can unintentionally upgrade dependencies on every release.

## Issue Context
- The workflow picks the language from `parse-release-tag.yml` outputs (java/ruby/python/dotnet/javascript/all) and feeds it into `./go <language>:update`.
- Many `:update` tasks upgrade dependency versions rather than only refreshing a lockfile to reflect the already-changed package version.

## Fix Focus Areas
- .github/workflows/release.yml[275-296]
- .github/workflows/parse-release-tag.yml[39-73]
- rake_tasks/java.rake[281-307]
- rake_tasks/node.rake[47-55]
- rake_tasks/dotnet.rake[105-109]
- rake_tasks/ruby.rake[220-226]
- rb/support/bundle_update.rb[20-39]

## What to change
- Replace `${language}:update` with a purpose-built “lockfile refresh only” task per affected ecosystem (or restrict the workflow to only the languages whose lockfiles require regeneration after version bump).
- Ensure `all` mode does not implicitly trigger broad dependency upgrades unless explicitly intended; if intended, rename job/commit message accordingly to reflect dependency upgrades, not lockfile refresh.

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

---

2. Rust version leaves stale lock ✓ Resolved 🐞 Bug ☼ Reliability

Description

rust:version no longer invokes rust:update, but callers like release_updates still call
rust:version without subsequently regenerating rust/Cargo.lock. This leaves rust/Cargo.lock’s
selenium-manager version entry unchanged even after updating rust/Cargo.toml, making the version
bump incomplete.

Code

rake_tasks/rust.rake[L64-68]

-  # Rake::Task#invoke is a no-op if the task has already run in this process
-  # (e.g. when chaining `./go rust:version X && ./go rust:version nightly`),
-  # so reenable before invoking to ensure Cargo.lock is refreshed every time.
-  Rake::Task['rust:update'].reenable
-  Rake::Task['rust:update'].invoke

Evidence

The deleted block in rust.rake shows rust:version used to explicitly re-enable and invoke
rust:update. The repo’s rust:update task is implemented as a Cargo operation to
update/regenerate rust/Cargo.lock, and the lockfile contains an explicit selenium-manager
version entry; meanwhile release_updates calls rust:version but not rust:update, so it will no
longer refresh the lockfile after this PR.

rake_tasks/rust.rake[26-33]
rake_tasks/rust.rake[42-63]
Rakefile[104-125]
rust/Cargo.lock[1858-1861]

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 PR removes the implicit `rust:update` invocation from `rust:version`. At least one existing caller (`release_updates`) invokes `rust:version` but does not invoke `rust:update`, so `rust/Cargo.lock` will no longer be regenerated/synced as part of that flow.

## Issue Context
- `rust:update` is explicitly described/implemented as regenerating `rust/Cargo.lock`.
- `rust/Cargo.lock` contains a `selenium-manager` package entry with an explicit version.
- `release_updates` calls `rust:version` but does not call `rust:update`.

## Fix Focus Areas
- Rakefile[104-125]
- rake_tasks/rust.rake[26-33]
- rust/Cargo.lock[1858-1861]

## What to change
- Update `release_updates` (and any other flows that require a synced `Cargo.lock`) to explicitly invoke `rust:update` after `rust:version`.
- If repeated invocations are expected in the same process, mirror the previous approach by re-enabling the task before invoking it.

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

---

[Copilot]

Pull request overview

Adjusts Selenium’s release automation so lockfile updates happen during the release workflow (when resetting versions to nightly) rather than being triggered implicitly by rust:version, to avoid unwanted lockfile churn during pre-release version bumps.

Changes:

• Removed the implicit rust:update invocation from the rust:version rake task.
• Added two new jobs to release.yml to update and commit dependency/lockfile changes before publishing nightly packages.

Reviewed changes

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

File	Description
rake_tasks/rust.rake	Stops rust:version from automatically regenerating Cargo.lock.
.github/workflows/release.yml	Adds “reset-dependencies” + “commit-dependencies” jobs and makes nightly publishing depend on them.

[qodo-code-review]

Persistent review updated to latest commit 245d8a8