[build] fetch the changelog history since the previous release tag instead of computing a depth

[titusfortner]

🔗 Related Issues

Builds on #16966 (replaces the compare-API commit count it introduced)

💥 What does this PR do?

• Simplify checkout logic for changelogs and dramatically improve performance

🔧 Implementation Notes

• Before: fetch-tags: true made actions/checkout fetch all 274 tags at the computed depth (--depth=83 +refs/tags/*:refs/tags/* for 4.49.0), three times per full release (changelogs, Rust changelogs, authors) and once per language release.
• After: each of the three jobs runs scripts/github-actions/deepen-fetch-to-tag.sh <release tag> before its ./go task. The script derives the previous release tag, fetches the checkout's history back through it by ancestry (--shallow-exclude plus --deepen=1), and fetches the tags that release line's changelogs look up. The calculate-changelog-depth job and its compare API call go away, and bazel.yml loses its now-unused fetch-depth input and the fetch-tags line.
• The tags are fetched only after the history is in place and only for the previous line (or the single previous tag for a patch release), so every one points at a commit already present and nothing is re-shallowed; fetching them at depth 1 up front would truncate the log at any intermediate tag.
• Patch releases now name the previous tag with its language suffix (selenium-4.34.1-python); the old code omitted it and silently fell back to full history.
• The Python and Ruby changelog tasks now pass python and ruby to update_changelog, so a patch release after .1 looks up the tag that exists (-python, not -py).
• X.0.0 releases resolve the highest tag of the previous major with ls-remote instead of fetching full history.
• Verified against github.com (including fetching by a non-tip SHA) and in depth-1 clones for a minor release across the 4.34 line, where two Python patch tags sit between 4.34.0 and 4.35.0 (135 of 135 commits, all tags present), a 4.34.2-python patch release (10 of 10, only its previous tag), and a 5.0.0 release resolving selenium-4.49.0.

Per full release (3 parallel fetches)	Before	After	Improvement
Data	4.8 GB	135 MB	97%
Wall clock, best case	2 min	about 10 s	over 90%
Wall clock, worst case	27 min (4.48.0)!	about 10 s	over 99%

After times come from regular trunk CI checkouts of the same shallow shape (5 to 9 s); over loopback a single fetch is 26 s before vs 0.4 s after.

🤖 AI assistance

• AI assisted (complete below)
  • Tool(s): Claude Code (Claude Fable 5.1)
  • What was generated: review of the fetch sequence, the shallow-clone verification, the patch-tag fix, and this description
  • I reviewed all AI output and can explain the change

🔄 Types of changes

• Bug fix (backwards compatible)

[qodo-code-review]

PR Summary by Qodo

Fetch release changelog history from the previous tag

🐞 Bug fix ✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Replaces commit-count depth calculation with tag-bounded shallow history fetches.
• Fetches only tags from the relevant release line for changelog generation.
• Fixes previous-tag resolution for language patches and new major releases.

Diagram

graph TD
  A["Release Input"] --> B["Previous Tag"] --> C["Bazel Workflow"] --> D["Shallow Checkout"] --> E["Tag-Bounded Fetch"] --> F["Release Generators"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Retain compare-API depth calculation

• ➕ Keeps checkout behavior centered on a numeric fetch depth.
• ➕ Requires fewer custom Git fetch commands.
• ➖ Adds an API request and depends on compare-count accuracy.
• ➖ Fetches every tag and substantially more repository data.
• ➖ Requires fallback behavior when comparison fails.

2. Fetch complete repository history

• ➕ Simplifies history availability and avoids shallow-clone edge cases.
• ➕ Guarantees all tags and commit ranges are present.
• ➖ Transfers gigabytes during each release.
• ➖ Significantly increases release latency and runner resource usage.

Recommendation: Use the PR's tag-bounded shallow fetch. It directly models the changelog boundary, removes the compare API dependency, preserves the release commit exclusion semantics, and minimizes transferred history and tags. The Git fetch ordering is specialized but justified by shallow-tag behavior.

Files changed (2) +32 / -35

Bug fix (1) +18 / -27

pre-release.ymlResolve and propagate the previous release tag +18/-27

Resolve and propagate the previous release tag

• Replaces compare-API commit counting with direct previous-tag resolution and passes that tag to changelog and author jobs. Language patch tags now include their suffix, while first releases of a major resolve the highest stable tag from the previous major.

.github/workflows/pre-release.yml

Other (1) +14 / -8

bazel.ymlAdd tag-bounded history fetching to reusable Bazel jobs +14/-8

Add tag-bounded history fetching to reusable Bazel jobs

• Replaces the explicit fetch-depth input with a since-tag input. After checkout, the workflow fetches history through that tag, deepens once to preserve changelog range semantics, and retrieves only tags from the matching release line.

.github/workflows/bazel.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📜 Skill insights (0)

1. Two fetch comments narrate commands ✗ Dismissed 📘 Rule violation ⚙ Maintainability ⭐ New

Description

Comments at lines 11 and 18 paraphrase the immediately following previous-tag selection and history
fetch rather than recording why those choices are necessary. A later change to release selection or
shallow-fetch behavior gets no preserved rationale for the non-obvious constraints behind these
steps.

Code

scripts/github-actions/deepen-fetch-to-tag.sh[11]

+# Determine the previous release tag to compare against depending on tag pattern

Evidence

Compliance rule 7 prohibits comments that merely restate implementation. The comments before the
tag-selection branch and the first fetch directly narrate the adjacent commands without explaining
their non-obvious design constraints.

AGENTS.md: Write Comments That Explain Rationale Rather Than Restating Code
scripts/github-actions/deepen-fetch-to-tag.sh[11-19]

Agent prompt

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

## Issue description
Two comments merely describe the operations performed by the following code instead of explaining the release-history constraints that require those operations.

## Fix Focus Areas
- scripts/github-actions/deepen-fetch-to-tag.sh[11-19]

## Recommended Fix
Remove comments that are already expressed by the code, or replace them with concise rationale explaining why the selected prior tag must bound the history and why this fetch sequence is necessary for a shallow checkout.

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

---

2. Release fetch regressions go undetected 📘 Rule violation ☼ Reliability ⭐ New

Description

deepen-fetch-to-tag.sh adds untested branch logic for patch, minor, and first-major releases plus
a multi-step shallow Git fetch. A change to tag derivation or fetch ordering can therefore break
changelog and author generation without a focused test failing before the pre-release workflow runs.

Code

scripts/github-actions/deepen-fetch-to-tag.sh[R12-15]

+if [ "$patch" -gt 1 ]; then previous_release="selenium-${major}.${minor}.$((patch-1))-${language}"
+elif [ "$patch" -eq 1 ]; then previous_release="selenium-${major}.${minor}.0"
+elif [ "$minor" -gt 0 ]; then previous_release="selenium-${major}.$((minor-1)).0"
+else previous_release="$(git ls-remote --tags --refs origin "selenium-$((major-1)).*" | awk -F/ '{print $NF}' | grep -E '^selenium-[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -1)"

Evidence

Compliance rule 5 requires suitable focused regression coverage for changed behavior. The cited
script introduces multiple release-selection branches and Git-fetch operations, while repository
inspection found no automated test exercising this script or its minor, patch, and major paths.

AGENTS.md: Add Focused Tests Without Contract-Distorting Mocks
scripts/github-actions/deepen-fetch-to-tag.sh[9-30]

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 new release-history script has no automated coverage for its patch, minor, and first-major release paths or for the resulting shallow Git history and tag refs.

## Fix Focus Areas
- scripts/github-actions/deepen-fetch-to-tag.sh[9-30]

## Recommended Fix
Add focused tests using temporary local Git repositories and shallow clones. Cover patch, minor, and first-major tags, then assert that the expected previous tag, commit range, and release-line tag refs are available without introducing unintended shallow boundaries.

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

---

3. Fetch failures skip release updates ✗ Dismissed 🐞 Bug ☼ Reliability ⭐ New

Description

The new deepen-fetch-to-tag.sh ... && ./go ... commands run inside a pipeline whose status comes
from tee, so a failed fetch skips generation without failing the reusable workflow step. When a
tag is missing or a network fetch fails, the release pull request proceeds while marking the
resulting missing changelog, Rust changelog, or author patch as a successful no-op.

Code

.github/workflows/pre-release.yml[127]

+      run: ./scripts/github-actions/deepen-fetch-to-tag.sh ${{ needs.parse-tag.outputs.tag }} && ./go ${{ needs.parse-tag.outputs.language }}:changelogs

Evidence

All three new commands place the fetch before generation with &&. The reusable workflow pipes that
compound command into tee without enabling pipefail, while its diagnostics depend on the step
receiving a failure outcome; it then saves and uploads patches even when generation did not run, and
the pull-request workflow explicitly treats absent patches as skipped changes.

.github/workflows/pre-release.yml[120-148]
.github/workflows/bazel.yml[253-268]
.github/workflows/bazel.yml[297-309]
.github/workflows/pre-release.yml[162-203]

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 newly added release-history fetch can fail while the reusable Bazel workflow still reports success because its command output is piped through `tee` without `pipefail`. This permits release preparation to continue with missing changelog or author updates.

## Fix Focus Areas
- .github/workflows/bazel.yml[253-264]
- .github/workflows/pre-release.yml[120-148]

## Recommended Fix
Enable `pipefail` in the reusable workflow's Run Bazel shell block before executing the command pipeline, so a failure from either the fetch script or the chained `./go` task sets `steps.run-bazel.outcome` to failure and activates the existing rerun and failure-handling steps.

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

---

View high (3)

4. Changelogs and authors omit history ✓ Resolved 🐞 Bug ≡ Correctness

Description

The final tag fetch uses --depth=1, making each fetched release-line tag tip a shallow boundary
even when its commit was already fetched. When an intermediate language-patch tag is an ancestor of
the release branch, both git log <older-tag>...HEAD and the AUTHORS task's unrestricted git log
stop there, dropping earlier changes and contributors.

Code

.github/workflows/bazel.yml[147]

+          git fetch --no-tags --depth=1 origin "+refs/tags/${release_line}*:refs/tags/${release_line}*"

Evidence

The workflow first establishes the intended shallow history, then performs a depth-one wildcard
fetch for every tag on the release line. Git documents --depth as limiting history from each
fetched ref tip; the changelog implementation and AUTHORS task subsequently use revision walks that
respect those resulting shallow boundaries.

.github/workflows/bazel.yml[137-147]
rake_tasks/common.rb[82-90]
Rakefile[96-101]
🌐 Git documents that --depth limits fetched history to the specified number of commits from each remote ref tip and changes the depth of an existing shallow repository.

Agent prompt

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

## Issue description
Fetching all release-line tags with `--depth=1` adds their target commits as shallow boundaries. Intermediate language-release tags can consequently truncate the revision walks used to generate changelogs and AUTHORS.

## Fix Focus Areas
- .github/workflows/bazel.yml[144-147]

## Recommended Fix
Fetch the required tag refs without applying a new depth-one boundary to each tag target, while retaining the shallow boundary established by the history fetch. Add a check covering multiple language tags on the same release line and verify that changelog and AUTHORS logs match a full clone.

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

---

5. Major releases cannot build changelogs ✗ Dismissed 📘 Rule violation ≡ Correctness

Description

previous-release-tag selects the highest unsuffixed tag from the preceding major for an X.0.0
release, but the fetch step only uses it to shape the checkout while SeleniumRake.previous_tag
independently decrements the current minor and derives selenium-X.-1.0. On the first release of a
major, every binding changelog task passes that nonexistent ref to git log instead of using the
fetched prior-major tag, and no focused contract test covers this branch.

Code

.github/workflows/pre-release.yml[R148-149]

+              # First release of a major version: the highest release tag of the previous major
+              PREV=$(gh api --paginate "repos/${{ github.repository }}/git/matching-refs/tags/selenium-$((MAJOR-1))." --jq '.[].ref' | sed 's|refs/tags/||' | grep -E '^selenium-[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -1)

Evidence

Rule 5 requires focused coverage for behavioral changes, yet the new workflow branch resolves a
previous-major tag and supplies it only to the fetch workflow. The changelog helper separately
decrements the current minor and passes the resulting value to a checked git log command, so a
version such as 5.0.0 becomes the invalid selenium-5.-1.0 rather than the fetched Selenium 4
tag, with no focused test exercising this contract.

AGENTS.md: Add Focused Tests for Behavioral Changes and Prefer Real Contracts Over Mocks
.github/workflows/pre-release.yml[136-163]
.github/workflows/bazel.yml[138-148]
rake_tasks/common.rb[57-90]
.github/workflows/pre-release.yml[145-163]
rake_tasks/common.rb[57-73]
rake_tasks/common.rb[82-90]

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 new major-release branch fetches the highest unsuffixed tag from the previous major, but changelog generation independently re-derives `selenium-X.-1.0` for an `X.0.0` release. The changelog jobs therefore fail despite the correct history being available, and the changed workflow lacks focused coverage for this contract.

## Fix Focus Areas
- .github/workflows/pre-release.yml[136-163]
- .github/workflows/bazel.yml[138-148]
- rake_tasks/common.rb[57-90]

## Recommended Fix
Pass the resolved previous-release tag through to changelog generation, or update the shared `previous_tag` resolver so a minor-zero release selects the highest unsuffixed tag from the preceding major. Add focused tests covering major, minor, first-patch, and later-patch releases, including a first release of a new major, and assert the exact tag passed to `git log`.

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

---

6. Python and Ruby patch releases fail ✓ Resolved 🐞 Bug ≡ Correctness

Description

previous-release-tag now selects full language suffixes such as -python and -ruby, while
SeleniumRake.previous_tag still constructs the changelog range with -py and -rb. On patch
versions greater than one, the workflow fetches the real prior release tag but git log references
a nonexistent short-suffix tag and aborts changelog generation.

Code

.github/workflows/pre-release.yml[R141-142]

            if [ "$PATCH" -gt 1 ]; then
-              PREV="selenium-${MAJOR}.${MINOR}.$((PATCH-1))"
+              PREV="selenium-${MAJOR}.${MINOR}.$((PATCH-1))-${LANGUAGE}"

Evidence

The release parser accepts the full suffixes python and ruby, and release creation uses the
parsed tag unchanged. In contrast, the Python and Ruby changelog tasks pass py and rb;
previous_tag appends those values directly, and update_changelog raises when git log cannot
resolve the resulting tag.

.github/workflows/parse-release-tag.yml[39-70]
.github/workflows/release.yml[86-98]
rake_tasks/python.rake[158-162]
rake_tasks/ruby.rake[164-168]
rake_tasks/common.rb[57-64]
rake_tasks/common.rb[82-90]

Agent prompt

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

## Issue description
Python and Ruby patch changelogs calculate prior tags with `-py` and `-rb`, although release tags and the new fetch workflow use `-python` and `-ruby`. This makes `git log` fail for patch versions greater than one.

## Fix Focus Areas
- rake_tasks/common.rb[57-73]
- rake_tasks/python.rake[158-162]
- rake_tasks/ruby.rake[164-168]
- .github/workflows/pre-release.yml[141-142]

## Recommended Fix
Normalize changelog identifiers to release-tag suffixes when constructing or searching for previous tags, mapping `py` to `python` and `rb` to `ruby`. Add coverage for Python and Ruby patch versions greater than one.

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

---

7. Binding changelogs repeat old entries ✗ Dismissed 🐞 Bug ≡ Correctness

Description

previous_tag reverses the lexicographically ordered git.tags list and takes the first suffix
match, and the new python and ruby arguments activate this branch for those full-release
changelogs. Once a release line has patches .9 and .10, reverse lexical order chooses .9, so
the next full release includes changes already shipped and recorded in .10 for both bindings.

Code

rake_tasks/python.rake[161]

+  SeleniumRake.update_changelog(python_version, 'python', 'py/selenium/webdriver', 'py/CHANGES', header)

Evidence

The changed task argument reaches previous_tag, whose full-release branch reverses the Git tag
list without version-aware sorting; the selected tag becomes the lower bound of the changelog log
range. Git documents that tag output defaults to lexicographic order unless configured otherwise,
meaning .9 sorts after .10 and is encountered first after reversal.

rake_tasks/python.rake[158-161]
rake_tasks/ruby.rake[164-167]
rake_tasks/common.rb[57-72]
rake_tasks/common.rb[82-90]
🌐 Git documents that tag sorting defaults to lexicographic order unless tag.sort or an explicit version-aware sort is configured.

Agent prompt

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

## Issue description
Python and Ruby full-release changelogs now search language-specific tags, but `previous_tag` selects from reverse lexicographic tag order. Two-digit patch numbers therefore sort incorrectly and can cause already released changes to be included again.

## Fix Focus Areas
- rake_tasks/common.rb[69-72]
- rake_tasks/python.rake[158-161]
- rake_tasks/ruby.rake[164-167]

## Recommended Fix
Collect all matching language tags and select the tag with the greatest numeric patch component rather than reversing Git's default tag order. Add coverage showing that `.10` is selected over `.9` for both Python and Ruby full-release changelogs.

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

---

8. A new tag comment only narrates code ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

The comment above the prior-major lookup describes the else condition and the value assigned to
PREV rather than explaining why that tag-selection strategy is necessary. If tag conventions
change later, readers receive no rationale for choosing the highest unsuffixed release while
excluding language-specific tags.

Code

.github/workflows/pre-release.yml[148]

+              # First release of a major version: the highest release tag of the previous major

Evidence

Rule 7 reserves comments for rationale rather than descriptions of visible behavior. The cited
comment repeats that this branch handles the first release of a major and obtains the highest
prior-major release tag, which the condition and command already express.

AGENTS.md: Write Comments That Explain Rationale Rather Than Restating Code
.github/workflows/pre-release.yml[148-149]

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 new comment narrates the adjacent branch and assignment instead of documenting the reason for selecting the highest unsuffixed tag from the previous major.

## Fix Focus Areas
- .github/workflows/pre-release.yml[148-149]

## Recommended Fix
Replace the comment with the non-obvious rationale for using the previous major's highest unsuffixed release tag and excluding binding-specific tags, or remove it if the code is sufficiently self-explanatory.

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

---

Context sources

Review mode: 🧠 Deep: This push contains several independent, substantive behavior changes across Java HTTP lifecycle/tracing, release-fetch CI scripting, and BiDi protocol generation, creating a dense set of easy-to-miss defect paths.

Tip of the day

💡 Did you know, you can enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit f41d1ed

Results up to commit b75556f ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Python and Ruby patch releases fail ✓ Resolved 🐞 Bug ≡ Correctness

Description

previous-release-tag now selects full language suffixes such as -python and -ruby, while
SeleniumRake.previous_tag still constructs the changelog range with -py and -rb. On patch
versions greater than one, the workflow fetches the real prior release tag but git log references
a nonexistent short-suffix tag and aborts changelog generation.

Code

.github/workflows/pre-release.yml[R141-142]

            if [ "$PATCH" -gt 1 ]; then
-              PREV="selenium-${MAJOR}.${MINOR}.$((PATCH-1))"
+              PREV="selenium-${MAJOR}.${MINOR}.$((PATCH-1))-${LANGUAGE}"

Evidence

The release parser accepts the full suffixes python and ruby, and release creation uses the
parsed tag unchanged. In contrast, the Python and Ruby changelog tasks pass py and rb;
previous_tag appends those values directly, and update_changelog raises when git log cannot
resolve the resulting tag.

.github/workflows/parse-release-tag.yml[39-70]
.github/workflows/release.yml[86-98]
rake_tasks/python.rake[158-162]
rake_tasks/ruby.rake[164-168]
rake_tasks/common.rb[57-64]
rake_tasks/common.rb[82-90]

Agent prompt

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

## Issue description
Python and Ruby patch changelogs calculate prior tags with `-py` and `-rb`, although release tags and the new fetch workflow use `-python` and `-ruby`. This makes `git log` fail for patch versions greater than one.

## Fix Focus Areas
- rake_tasks/common.rb[57-73]
- rake_tasks/python.rake[158-162]
- rake_tasks/ruby.rake[164-168]
- .github/workflows/pre-release.yml[141-142]

## Recommended Fix
Normalize changelog identifiers to release-tag suffixes when constructing or searching for previous tags, mapping `py` to `python` and `rb` to `ruby`. Add coverage for Python and Ruby patch versions greater than one.

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

---

2. Major releases cannot build changelogs ✗ Dismissed 📘 Rule violation ≡ Correctness

Description

previous-release-tag selects the highest unsuffixed tag from the preceding major for an X.0.0
release, but the fetch step only uses it to shape the checkout while SeleniumRake.previous_tag
independently decrements the current minor and derives selenium-X.-1.0. On the first release of a
major, every binding changelog task passes that nonexistent ref to git log instead of using the
fetched prior-major tag, and no focused contract test covers this branch.

Code

.github/workflows/pre-release.yml[R148-149]

+              # First release of a major version: the highest release tag of the previous major
+              PREV=$(gh api --paginate "repos/${{ github.repository }}/git/matching-refs/tags/selenium-$((MAJOR-1))." --jq '.[].ref' | sed 's|refs/tags/||' | grep -E '^selenium-[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -1)

Evidence

Rule 5 requires focused coverage for behavioral changes, yet the new workflow branch resolves a
previous-major tag and supplies it only to the fetch workflow. The changelog helper separately
decrements the current minor and passes the resulting value to a checked git log command, so a
version such as 5.0.0 becomes the invalid selenium-5.-1.0 rather than the fetched Selenium 4
tag, with no focused test exercising this contract.

AGENTS.md: Add Focused Tests for Behavioral Changes and Prefer Real Contracts Over Mocks
.github/workflows/pre-release.yml[136-163]
.github/workflows/bazel.yml[138-148]
rake_tasks/common.rb[57-90]
.github/workflows/pre-release.yml[145-163]
rake_tasks/common.rb[57-73]
rake_tasks/common.rb[82-90]

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 new major-release branch fetches the highest unsuffixed tag from the previous major, but changelog generation independently re-derives `selenium-X.-1.0` for an `X.0.0` release. The changelog jobs therefore fail despite the correct history being available, and the changed workflow lacks focused coverage for this contract.

## Fix Focus Areas
- .github/workflows/pre-release.yml[136-163]
- .github/workflows/bazel.yml[138-148]
- rake_tasks/common.rb[57-90]

## Recommended Fix
Pass the resolved previous-release tag through to changelog generation, or update the shared `previous_tag` resolver so a minor-zero release selects the highest unsuffixed tag from the preceding major. Add focused tests covering major, minor, first-patch, and later-patch releases, including a first release of a new major, and assert the exact tag passed to `git log`.

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

---

3. A new tag comment only narrates code ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

The comment above the prior-major lookup describes the else condition and the value assigned to
PREV rather than explaining why that tag-selection strategy is necessary. If tag conventions
change later, readers receive no rationale for choosing the highest unsuffixed release while
excluding language-specific tags.

Code

.github/workflows/pre-release.yml[148]

+              # First release of a major version: the highest release tag of the previous major

Evidence

Rule 7 reserves comments for rationale rather than descriptions of visible behavior. The cited
comment repeats that this branch handles the first release of a major and obtains the highest
prior-major release tag, which the condition and command already express.

AGENTS.md: Write Comments That Explain Rationale Rather Than Restating Code
.github/workflows/pre-release.yml[148-149]

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 new comment narrates the adjacent branch and assignment instead of documenting the reason for selecting the highest unsuffixed tag from the previous major.

## Fix Focus Areas
- .github/workflows/pre-release.yml[148-149]

## Recommended Fix
Replace the comment with the non-obvious rationale for using the previous major's highest unsuffixed release tag and excluding binding-specific tags, or remove it if the code is sufficiently self-explanatory.

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

---

Results up to commit 7e818bb ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Changelogs and authors omit history ✓ Resolved 🐞 Bug ≡ Correctness

Description

The final tag fetch uses --depth=1, making each fetched release-line tag tip a shallow boundary
even when its commit was already fetched. When an intermediate language-patch tag is an ancestor of
the release branch, both git log <older-tag>...HEAD and the AUTHORS task's unrestricted git log
stop there, dropping earlier changes and contributors.

Code

.github/workflows/bazel.yml[147]

+          git fetch --no-tags --depth=1 origin "+refs/tags/${release_line}*:refs/tags/${release_line}*"

Evidence

The workflow first establishes the intended shallow history, then performs a depth-one wildcard
fetch for every tag on the release line. Git documents --depth as limiting history from each
fetched ref tip; the changelog implementation and AUTHORS task subsequently use revision walks that
respect those resulting shallow boundaries.

.github/workflows/bazel.yml[137-147]
rake_tasks/common.rb[82-90]
Rakefile[96-101]
🌐 Git documents that --depth limits fetched history to the specified number of commits from each remote ref tip and changes the depth of an existing shallow repository.

Agent prompt

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

## Issue description
Fetching all release-line tags with `--depth=1` adds their target commits as shallow boundaries. Intermediate language-release tags can consequently truncate the revision walks used to generate changelogs and AUTHORS.

## Fix Focus Areas
- .github/workflows/bazel.yml[144-147]

## Recommended Fix
Fetch the required tag refs without applying a new depth-one boundary to each tag target, while retaining the shallow boundary established by the history fetch. Add a check covering multiple language tags on the same release line and verify that changelog and AUTHORS logs match a full clone.

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

---

Results up to commit f11a01d ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Binding changelogs repeat old entries ✗ Dismissed 🐞 Bug ≡ Correctness

Description

previous_tag reverses the lexicographically ordered git.tags list and takes the first suffix
match, and the new python and ruby arguments activate this branch for those full-release
changelogs. Once a release line has patches .9 and .10, reverse lexical order chooses .9, so
the next full release includes changes already shipped and recorded in .10 for both bindings.

Code

rake_tasks/python.rake[161]

+  SeleniumRake.update_changelog(python_version, 'python', 'py/selenium/webdriver', 'py/CHANGES', header)

Evidence

The changed task argument reaches previous_tag, whose full-release branch reverses the Git tag
list without version-aware sorting; the selected tag becomes the lower bound of the changelog log
range. Git documents that tag output defaults to lexicographic order unless configured otherwise,
meaning .9 sorts after .10 and is encountered first after reversal.

rake_tasks/python.rake[158-161]
rake_tasks/ruby.rake[164-167]
rake_tasks/common.rb[57-72]
rake_tasks/common.rb[82-90]
🌐 Git documents that tag sorting defaults to lexicographic order unless tag.sort or an explicit version-aware sort is configured.

Agent prompt

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

## Issue description
Python and Ruby full-release changelogs now search language-specific tags, but `previous_tag` selects from reverse lexicographic tag order. Two-digit patch numbers therefore sort incorrectly and can cause already released changes to be included again.

## Fix Focus Areas
- rake_tasks/common.rb[69-72]
- rake_tasks/python.rake[158-161]
- rake_tasks/ruby.rake[164-167]

## Recommended Fix
Collect all matching language tags and select the tag with the greatest numeric patch component rather than reversing Git's default tag order. Add coverage showing that `.10` is selected over `.9` for both Python and Ruby full-release changelogs.

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

---

[qodo-code-review]

Code review by qodo was updated up to the latest commit 7e818bb

[qodo-code-review]

Code review by qodo was updated up to the latest commit f11a01d

[qodo-code-review]

Code review by qodo was updated up to the latest commit f41d1ed