Skip to content

[release] Skip release if package is already published - #17686

Merged
diemol merged 1 commit into
trunkfrom
skip-release-if-already-published
Jun 17, 2026
Merged

[release] Skip release if package is already published#17686
diemol merged 1 commit into
trunkfrom
skip-release-if-already-published

Conversation

@diemol

@diemol diemol commented Jun 16, 2026

Copy link
Copy Markdown
Member

💥 What does this PR do?

Invoke the :verify task at the start of each language binding's :release task. If the package is already published on the registry, skip the release and print a message rather than failing or re-publishing. This allows re-running a release locally after a partial CI failure without needing to re-push artifacts that already landed.

🤖 AI assistance

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

🔄 Types of changes

  • Bug fix (backwards compatible)

Invoke the :verify task at the start of each language binding's :release
task. If the package is already published on the registry, skip the
release and print a message rather than failing or re-publishing. This
allows re-running a release locally after a partial CI failure without
needing to re-push artifacts that already landed.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@qodo-code-review

Copy link
Copy Markdown
Contributor

Looking for bugs?

Check back in a few minutes. An AI review agent is analyzing this pull request.

@selenium-ci selenium-ci added the B-build Includes scripting, bazel and CI integrations label Jun 16, 2026
@qodo-code-review

Copy link
Copy Markdown
Contributor

PR Summary by Qodo

Skip language binding releases when package is already published
🐞 Bug fix 🕐 10-20 Minutes

Grey Divider

Description

• Run each binding’s :verify before :release to detect already-published artifacts.
• Skip non-nightly (and non-dry-run for Node) releases when registry already has the version.
• Re-enable :verify after invocation to keep subsequent rake runs consistent.
Diagram

graph TD
  A["<lang>:release"] --> B["<lang>:verify"] --> C{Published?}
  C -->|Yes| D["Print skip message"] --> E(["End"])
  C -->|No| F["check_credentials"] --> G[("Package registry")] --> H["Publish artifacts"]
  subgraph Legend
    direction LR
    _task["Task"] ~~~ _dec{"Decision"} ~~~ _reg[("Registry")]
  end
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Make `:verify` return a boolean status (no exception control flow)
  • ➕ Clearer contract: true/false for published vs not published
  • ➕ Avoids rescuing broad StandardError (which can mask real failures)
  • ➕ Easier to test/extend with richer status (e.g., network error vs not found)
  • ➖ Requires changing all :verify tasks’ behavior/signature
  • ➖ Potentially more refactor than desired for a release-hotfix PR
2. Extract a shared helper for “skip-if-verified” across rake tasks
  • ➕ Removes copy/paste logic across language rakefiles
  • ➕ Keeps behavior consistent (including reenable/printing)
  • ➖ Adds indirection to otherwise straightforward rake tasks
  • ➖ May be awkward depending on how rake tasks are currently organized/loaded
3. Check registries directly in `:release` (API query) instead of invoking `:verify`
  • ➕ Separates “verification” from “publish gating” concerns
  • ➕ Can distinguish “already published” from “verification failed” more precisely
  • ➖ Re-implements logic that likely already exists in :verify
  • ➖ Adds registry/API surface area and maintenance burden

Recommendation: The current approach is pragmatic and low-risk for unblocking re-runs: it reuses existing :verify behavior and adds an early exit. If this pattern sticks, consider a follow-up to (1) narrow what gets rescued (or change :verify to return status) and (2) deduplicate the skip logic into a shared helper to avoid drift across bindings.

Files changed (5) +83 / -0

Bug fix (5) +83 / -0
dotnet.rakeSkip .NET release when 'dotnet:verify' indicates packages are published +17/-0

Skip .NET release when 'dotnet:verify' indicates packages are published

• Invokes 'dotnet:verify' at the start of 'dotnet:release' for non-nightly runs. If verification succeeds, prints a skip message and exits early; re-enables the verify task to keep subsequent invocations valid.

rake_tasks/dotnet.rake

java.rakeGate Java release on 'java:verify' and skip when already published +16/-0

Gate Java release on 'java:verify' and skip when already published

• Runs 'java:verify' before credential checks for non-nightly releases. Treats a successful verify as “already published,” prints a message, and short-circuits the release; re-enables the verify task afterward.

rake_tasks/java.rake

node.rakeSkip Node release when 'node:verify' passes (non-nightly, non-dry-run) +16/-0

Skip Node release when 'node:verify' passes (non-nightly, non-dry-run)

• Adds a preflight 'node:verify' invocation for normal releases (excluding 'nightly' and 'dry-run'). If verification succeeds, logs that the package is already published and exits early; re-enables the task to allow future runs.

rake_tasks/node.rake

python.rakeSkip Python release when 'py:verify' indicates artifacts already exist +17/-0

Skip Python release when 'py:verify' indicates artifacts already exist

• Runs 'py:verify' at the start of 'py:release' for non-nightly runs. On successful verify, prints a skip message and stops the release flow; ensures the verify task is re-enabled afterward.

rake_tasks/python.rake

ruby.rakeSkip Ruby gem release when 'rb:verify' passes +17/-0

Skip Ruby gem release when 'rb:verify' passes

• Invokes 'rb:verify' before performing credential checks for non-nightly releases. If verification succeeds, prints that gems are already published and exits early; re-enables 'rb:verify' for subsequent invocations.

rake_tasks/ruby.rake

@diemol
diemol merged commit 7641dd3 into trunk Jun 17, 2026
27 checks passed
@diemol
diemol deleted the skip-release-if-already-published branch June 17, 2026 09:25
This was referenced Jul 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

B-build Includes scripting, bazel and CI integrations

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants