[build] generate release notes from previous minor release tag

[titusfortner]

Last release I changed when nightly tag is removed, so release notes generated between nightly tag and release tag. This indicates it would also give the wrong list if there is a patch release.

💥 What does this PR do?

• Generates release notes between previous release and current release commits

🔧 Implementation Notes

🤖 AI assistance

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

🔄 Types of changes

• Bug fix (backwards compatible)

[qodo-code-review]

Review Summary by Qodo

Generate release notes from previous minor release tag

🐞 Bug fix

Walkthroughs

Description

• Generates release notes from previous minor release tag
• Filters releases to only consider minor versions (x.y.0)
• Replaces automatic release notes generation with targeted API call
• Ensures patch releases generate correct changelog content

Diagram

flowchart LR
  A["Release workflow"] --> B["Query previous minor release"]
  B --> C["Filter for x.y.0 pattern"]
  C --> D["Generate notes via API"]
  D --> E["Create draft release"]

Loading

File Changes

1. .github/workflows/release.yml 🐞 Bug fix +18/-2

Replace automatic release notes with targeted API generation

• Added new step to generate release notes against previous minor release tag
• Queries GitHub releases and filters for minor versions matching pattern
 selenium-[0-9]+\.[0-9]+\.0
• Uses GitHub API to generate notes between previous minor release and current tag
• Replaced automatic generateReleaseNotes flag with manual API call for precise control
• Changed release body source from static header file to dynamically generated release_body.md

.github/workflows/release.yml

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1)

1. PREV tag not validated 📘 Rule violation ☼ Reliability

Description

The workflow derives PREV from a filtered gh release list/jq [0] result and then
unconditionally uses it as previous_tag_name for releases/generate-notes without verifying a
previous tag was found, so it can generate notes from an empty/invalid baseline or fail
unpredictably. This violates the requirement to fail fast on missing prerequisites and can produce
incorrect or flaky release output.

Code

.github/workflows/release.yml[R104-113]

+          PREV=$(gh release list --exclude-drafts --json tagName \
+            -q 'map(.tagName | select(test("^selenium-[0-9]+\\.[0-9]+\\.0$")))[0]')
+          echo "Previous release tag: $PREV"
+          {
+            cat scripts/github-actions/release_header.md
+            echo ""
+            gh api -X POST "/repos/${{ github.repository }}/releases/generate-notes" \
+              -f tag_name="$TAG" \
+              -f previous_tag_name="$PREV" \
+              -f target_commitish="$SHA" \

Evidence

PR Compliance ID 11 requires CI/scripts to fail on missing prerequisites and behave
deterministically, but the workflow step computes PREV by taking the first ([0]) element of a
filtered release list and then passes that value straight into the GitHub release notes generation
API as previous_tag_name with no guard to stop the job when the filter yields no match (producing
empty/null). The repo’s pre-release.yml demonstrates an existing defensive pattern for
determining a previous tag from version parts with a safe fallback when it can’t be determined,
highlighting that the current release.yml behavior lacks comparable validation.

.github/workflows/release.yml[99-115]
.github/workflows/pre-release.yml[164-195]
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 release workflow computes `PREV` from `gh release list ...` (via a jq `[0]` index over a filtered list) and then uses it as `previous_tag_name` in the `releases/generate-notes` API call without checking whether a valid previous release tag was found. If the filtered list is empty (first release, tag pattern mismatch, API output changes), `PREV` can be empty/`null`, causing the job to fail unpredictably or generate release notes against a non-existent/incorrect baseline instead of failing fast.

## Issue Context
Compliance requires build/CI scripts to fail on missing prerequisites and behave deterministically rather than masking errors or producing non-deterministic output. This repo also has an established defensive pattern in `pre-release.yml` that deterministically computes a previous tag from version parts and falls back safely when it can’t be determined.

## Fix Focus Areas
- .github/workflows/release.yml[99-115]
- .github/workflows/pre-release.yml[164-195]

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

---

[Copilot]

Pull request overview

Updates the release workflow to generate GitHub release notes against the previous minor release tag (e.g., selenium-X.Y.0) rather than relying on ncipollo/release-action's automatic generation, which previously used the most recent prior tag (incorrect for patch releases or after the nightly tag was removed).

Changes:

• New workflow step queries gh release list, picks the most recent selenium-X.Y.0 tag, and calls the GitHub releases/generate-notes API with that as previous_tag_name.
• Concatenates release_header.md with the generated notes into release_body.md.
• ncipollo/release-action now uses bodyFile: release_body.md instead of bodyFile: release_header.md + generateReleaseNotes: true.