• Add error handling for already-published packages across languages
  - Node.js: rescue npm publish errors for previously published versions
  - Ruby: extract gem publishing logic with duplicate version detection
  - Python: enable skip-existing flag in PyPI publish action
• Create release tags unconditionally at workflow start
  - Check if tag exists before creation to support workflow reruns
  - Remove language-specific tag creation condition
• Prevent Java release reruns with explicit error message
  - Fail fast on Java rerun attempts due to staging repo complexity
• Update workflow job dependencies to reflect tag creation changes

Add error handling for npm duplicate versions

• Wrap Bazel.execute call in begin-rescue block to catch npm publish errors
• Skip release if error message matches "cannot publish over the previously published"
• Only rescue errors in non-dry-run mode to preserve dry-run error reporting

rake_tasks/node.rake

Extract gem publishing with duplicate detection

• Extract gem publishing logic into new publish_gem helper function
• Function rescues "Repushing of gem versions" errors and logs skip message
• Replace inline error handling with calls to publish_gem for both nightly and release tasks
• Simplifies code by centralizing duplicate version detection logic

rake_tasks/ruby.rake

Make workflow rerun-safe with tag and language checks

• Rename create-language-tag job to create-tag and remove language condition
• Add tag existence check before creation to support workflow reruns
• Add Java rerun prevention with explicit error message directing to staging repo
• Add skip-existing: true parameter to PyPI publish action
• Update all job dependencies from create-language-tag to create-tag
• Update Slack notification to reference new job name

.github/workflows/release.yml

Description

The publish matrix exits with an error on any rerun for the Java entry before it checks whether Java
is actually being released, so rerunning a ruby/dotnet/javascript-only release will still fail due
to Java. This prevents reruns for non-Java patch releases (and any rerun attempt >1) even when Java
would otherwise be skipped.

Code

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

+        if [ "${{ matrix.language == 'java' && github.run_attempt != '1' }}" = "true" ]; then
+          echo "::error::Java release is not yet rerun-safe — check/drop the staging repo at https://central.sonatype.com/publishing/deployments and publish manually"
+          exit 1
+        fi

Evidence

publish always includes java in its matrix, and the new Java rerun guard runs before checking
whether the selected release language matches the matrix entry; for a non-Java patch release,
parse-tag outputs a specific language (e.g., ruby), so Java should be skipped but instead fails
on rerun attempts > 1.

.github/workflows/release.yml[129-155]
.github/workflows/parse-release-tag.yml[39-73]

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 publish matrix currently fails on rerun attempts (`github.run_attempt != '1'`) for the Java matrix entry even when the workflow is releasing a different language (e.g., `selenium-4.28.1-ruby`). This happens because the Java rerun guard runs before the “is this language selected?” check.

## Issue Context
- `publish` runs a matrix over `[java, ruby, dotnet, javascript]`.
- For patch releases, `parse-tag` sets `outputs.language` to the tag suffix (e.g., `ruby`).
- On reruns, the Java matrix entry should *skip* when `outputs.language != 'java'`, but it currently fails early.

## Fix
Move or gate the Java rerun guard so it only triggers when Java is actually being released:

Option A (recommended): nest the Java guard inside the selected-language branch:
```bash
if [ "${{ needs.parse-tag.outputs.language == 'all' || needs.parse-tag.outputs.language == matrix.language }}" = "true" ]; then
 if [ "${{ matrix.language == 'java' && github.run_attempt != '1' }}" = "true" ]; then
   echo "::error::Java release is not yet rerun-safe — ..."
   exit 1
 fi
 ./go ${{ matrix.language }}:release
else
 echo skipping
fi
```

Option B: add the selected-language predicate directly into the Java guard condition.

## Fix Focus Areas
- .github/workflows/release.yml[144-153]

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

Description

The new create-tag step assumes TAG and SHA are non-empty and valid before calling gh api to
create a git ref. If either value is missing/empty, the workflow can create or attempt to create an
incorrect ref (or fail in a non-obvious way), violating the requirement to validate CI preconditions
and fail safely.

Code

.github/workflows/release.yml[R78-88]

          GH_TOKEN: ${{ secrets.SELENIUM_CI_TOKEN }}
          TAG: ${{ needs.parse-tag.outputs.tag }}
          SHA: ${{ github.event.pull_request.merge_commit_sha || github.sha }}
        run: |
+          if gh api "/repos/${{ github.repository }}/git/ref/tags/${TAG}" >/dev/null 2>&1; then
+            echo "Tag ${TAG} already exists — skipping creation."
+            exit 0
+          fi
          gh api -X POST /repos/${{ github.repository }}/git/refs \
            -f ref="refs/tags/${TAG}" \
            -f sha="${SHA}"

Evidence

Rule 10 requires validating preconditions/inputs in CI automation and failing safely on errors. The
added tag-creation script uses TAG/SHA directly in gh api calls without checking that they are
set/non-empty before proceeding.

.github/workflows/release.yml[78-88]
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 workflow creates a git tag using `TAG` and `SHA` without validating they are present and well-formed.

## Issue Context
Per CI/automation safety expectations, required inputs should be validated explicitly so reruns and unusual triggers fail deterministically with actionable errors.

## Fix Focus Areas
- .github/workflows/release.yml[78-88]

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