ci(publish): skip notify/publish when version is already released#1606
Open
ci(publish): skip notify/publish when version is already released#1606
Conversation
|
There was a problem hiding this comment.
Pull request overview
Adds a version check to the publish workflow so that notify/publish steps are skipped when the workspace version is already the latest GitHub release, avoiding unnecessary approval gates and notifications on no-op pushes.
Changes:
- Added
infra publish checksubcommand to compare local workspace version vs latest GitHub release and emit apublishNeededGitHub Actions output. - Wired the new
publishNeededoutput into the workflow to gatenotify-deployandpublishjobs. - Updated the publish workflow documentation matrix to reflect the new “push (no-op)” path.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
crates/infra/cli/src/commands/publish/mod.rs |
Registers the new publish check subcommand in the CLI. |
crates/infra/cli/src/commands/publish/check.rs |
Implements version comparison and writes publishNeeded to GITHUB_OUTPUT. |
.github/workflows/publish.yml |
Adds the check step/output and gates notify/publish jobs on publishNeeded. |
The publish workflow triggered notify-deploy and the publish approval gate on every push to main without pending changesets, even when the workspace version already matched the latest GitHub release. This added an `infra publish check` subcommand that compares local vs published versions, and gates notify-deploy/publish on the result.
The check command is self-contained and the downstream jobs already gate on hasChangesets independently.
The struct has no fields but uses &self to match the execute() signature pattern used by all other publish controllers.
Instead of printing a parseable line and capturing it in shell, write directly to the GITHUB_OUTPUT file when running in CI. This simplifies the workflow step to a plain command invocation.
- Let latest_release_version() errors propagate instead of silently treating any failure as "no release found". This avoids masking auth, network, or parse errors as false publish-needed signals. - Pass GH_TOKEN to the workflow step so gh api is authenticated.
The Rust subcommand was CI-only glue with no local utility. A simple shell comparison of the Cargo.toml version against the latest GitHub release tag achieves the same result with less code to maintain.
The gh api call to fetch the latest release will 404 if no release exists yet (or if the latest is a draft/prerelease). Catch this error gracefully and treat it as "publish needed" with a clear log message, rather than failing the entire changesets job.
nebasuke
force-pushed
the
slang/publish-check
branch
from
bfbc3cc to
55bf464
Compare
Replace inline shell (grep/sed + gh api) with Octokit's getReleaseByTag via actions/github-script. This gives explicit 404 handling for the "no release yet" case while letting real errors (auth, network, rate limit) fail the step loudly instead of being silently swallowed.
Guard the checkVersion step with hasChangesets == 'false' so it only runs when publishing is actually possible. Avoids unnecessary API calls and prevents a release API failure from blocking the entire changesets job when there are pending changesets.
When the checkVersion step is skipped (changesets pending), the output was implicitly empty. Add an explicit || 'false' fallback so downstream job conditions don't rely on empty-string-is-not-true semantics.
OmarTawfik
reviewed
Apr 9, 2026
| uses: "actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea" # v7.0.1 | ||
| with: | ||
| script: | | ||
| const fs = require('fs'); |
Contributor
There was a problem hiding this comment.
we already have the logic to check if a release is needed in infra publish for npm/cargo/github tags. WDYT of exposing that through the CLI instead? that would keep both in sync. Something along the lines of:
- name: "infra check"
run: "./scripts/bin/infra publish github-release --check-only" # prints 'true' or 'false'
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The publish workflow triggered notify-deploy and the publish approval gate on every push to main without pending changesets, even when the workspace version already matched the latest GitHub release. This caused unnecessary Slack notifications and approval prompts on no-op merges.
This PR adds a version check step to the changesets job that compares the local Cargo.toml version against the GitHub release for that tag:
rate limit) fail the step loudly
blocking the changesets job when publishing isn't relevant
relying on empty-string semantics
Updated the workflow header table to reflect the new push (no-op) row.