Repository navigation
Add release-publish: the GitHub release for a version at a commit, with a title, notes and assets - #16
Open
glaubersilva wants to merge 7 commits into
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
 |
| Layer / File(s) | Summary |
|---|---|
Action inputs and release data .github/actions/release-publish/action.yml, .github/actions/release-publish/release-publish.js, .github/actions/release-publish/README.md |
The action defines version, target, title, notes, asset, and token inputs, plus publishing outputs. It validates inputs, resolves a commit or branch, reads optional files, and determines whether the release is marked latest. The README documents the action and its execution. |
Release checks and publishing .github/actions/release-publish/release-publish.js, tests/actions/release-publish/*, tests/support/actions.js |
The action skips an existing release and refuses a tag without a release. It creates a release directly or uploads assets to a draft before publishing it. Tests cover API behavior, outputs, upload failures, input validation, and recorded request bodies. |
Workflow integration templates/workflows/release-publish.yml, templates/workflows/release-merge.yml, .github/actions/release-merge/action.yml, .github/actions/release-merge/README.md, README.md |
The new manual workflow invokes the publishing action with the checked-out commit SHA. Release-merge guidance directs callers to build before publishing at base-sha. The project checklist marks the action complete. |
Estimated code review effort: 3 (Moderate) | ~25 minutes
Change: Feature
Sequence Diagram(s)
sequenceDiagram
participant PublishWorkflow
participant ReleasePublishAction
participant GitHubAPI
participant CheckoutFiles
PublishWorkflow->>ReleasePublishAction: Pass version, target, title, and token
ReleasePublishAction->>GitHubAPI: Resolve target and check release and tag
ReleasePublishAction->>CheckoutFiles: Read optional notes and assets
ReleasePublishAction->>GitHubAPI: Create release or draft
ReleasePublishAction->>GitHubAPI: Upload assets and publish draft when assets exist
Possibly related PRs
- stellarwp/plugin-toolbox#12: The action uses helpers defined in this PR and refuses to publish when a tag exists without a release.
- stellarwp/plugin-toolbox#10: This PR uses the
base-shaoutput and version helpers added by that PR. - stellarwp/plugin-toolbox#7: This PR uses the shared version comparison helper to decide whether a release is marked latest.
Suggested labels: enhancement
Suggested reviewers: d4mation, larodiel
Merge Risk: 
ef353
-
The new release-publish template can race with the release-merge template when a repository uses both, can publish a branch other than the one the
liveenvironment's branch policy approved, and fails when the target commit changes workflow files. Fix these in the templates before merge. None of them affects repositories that use the action with the template's default scope.
Pre-merge checks: 
-
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check The title clearly identifies the main change: adding the release-publish action to create a GitHub release for a version at a commit with title, notes, and assets. Docstring Coverage Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat… Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Full details: Docstring Coverage
-
Explanation
Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 12 functions across 3 files. (2 skipped: 2 unsupported.)
-
Finishing Touches
-
Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
glaubersilva
added a commit
to impress-org/givewp
that referenced
this pull request
Nov 2, 2026
…p attached, through release-publish release-merge no longer publishes: the toolbox split the release into its own action, release-publish, run after the build at the commit the merge left on master. The release is created with give.zip already on it and only once the wp.org deploy succeeded, so a failed build or deploy leaves no release behind. Pinned to plugin-toolbox 657eb50 (stellarwp/plugin-toolbox#16).
glaubersilva
force-pushed
the
soft-5188-release-publish-action
branch
2 times, most recently
from
November 2, 2026 20:10
b529772 to
eab1115
Compare
glaubersilva
marked this pull request as ready for review
November 2, 2026 20:27
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
glaubersilva
changed the title
glaubersilva
force-pushed
the
soft-5188-release-publish-action
branch
from
November 2, 2026 20:46
05d78d2 to
9603173
Compare
glaubersilva
force-pushed
the
soft-5188-release-publish-action
branch
3 times, most recently
from
November 2, 2026 21:37
e6c9816 to
ef353a6
Compare
…le, notes and assets release-merge published the release as its second step, right after the merges and before the caller built anything, so a release went public without its build and a failed build left a published release behind; with immutable releases that could not be corrected. Publishing is now the release-publish action, which the caller runs after its build at the commit release-merge leaves on the base (its base-sha output). release-publish takes a title (the version by default), a notes file (GitHub's generated notes by default) and assets, one path per line. With assets the release is created as a draft, the files are uploaded, and the draft is published last: a draft makes no tag, so an upload that fails is undone by deleting it. A hotfix on an older line no longer takes Latest from a newer release (make_latest by version order). A release that already exists is skipped, as before. validateVersion moved to the shared lib for both actions. release-merge loses the publish input and the published / release-url outputs; the template runs the two actions with the build between them. SOFT-5188
…l publishes The merge template had grown a publish step. Each template now shows one action; a repository that merges with release-merge adds release-publish to that workflow after its build, as GiveWP's deploy workflow does, and the READMEs say so. SOFT-5188
The release-publish template checked out the branch, invited a build from that checkout, and passed the branch name as target, which the action resolves to the branch's tip when it runs: a push between the checkout and the publish would tag a commit other than the one the assets came from. The template now records the checked-out commit and passes it. SOFT-5188
…ispatches The per-action templates matched no repository: nobody merges without publishing, and a repository that only publishes does not go through the dashboard. release.yml, the name the dashboard looks for by default, runs release-merge, leaves room for the build, then release-publish at the merged commit. The publish-only shape stays as a snippet in release-publish's README. SOFT-5188
glaubersilva
force-pushed
the
soft-5188-release-publish-action
branch
from
November 2, 2026 21:49
ef353a6 to
879516b
Compare
…s github.token cannot create The environment's branch policy protects the branch a run is started on, not the branch input, so a run started on an allowed branch could merge and publish any other. The template's first step fails when the two differ; the dashboard starts the run on the release branch, and a hand dispatch passes --ref. A failing step rather than an if on the job, since a skipped job reads as a success to the dispatcher. The release-publish README also says that a release at a commit that changes a workflow file relative to the default branch needs a token allowed to modify workflows, which github.token cannot be; after release-merge the published commit is the base branch's tip, so the case is the hand-merged publish only. SOFT-5188
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.
Related
Part of SOFT-5188. Answers three review comments on #10: publish inputs,
make_latest, the token andon: release.Summary
release-publishcreates the GitHub release for a version at a commit: the tag and the release in one step, with a title, notes from a file and assets. A repository's deploy workflow runs it afterrelease-merge(#10) and its build, at the commitrelease-mergeleaves on the base branch (base-sha), so the release is published only once the build exists and carries it. A repository that merges by hand runs it alone, with a branch astarget.Changes
version,target(a commit hash; a branch name is resolved to its tip when the action runs, so a workflow that builds from a checkout passes that checkout's commit),title(the version by default),notes-file(a file in the checkout; GitHub's generated notes by default),files(assets, one path per line),token(defaultgithub.token). Outputs:published(trueorskipped),release-url,sha.files, the release is created as a draft, the files are uploaded, and the draft is published last. A draft makes no tag, so a failed upload is undone by deleting the draft; every path is checked before anything is created. A repository with immutable releases needs this order, since a published release cannot be changed.make_latestfollows version order against the repository's current latest release, so a hotfix on an older line does not take "Latest" from a newer release.templates/workflows/release.yml: the deploy workflow the dashboard dispatches, under the name it looks for by default. It runsrelease-merge, leaves room for the build, thenrelease-publishwithtarget: ${{ steps.merge.outputs.base-sha }}, as GiveWP's deploy workflow does. Its first step fails when the run was not started on the branch it is asked to merge, so theliveenvironment's branch policy covers what is merged and published; the dashboard starts the run on the release branch, a hand dispatch passes--ref. The merge-only template is gone (Add release-merge: the release branch into the base branch, then the base branch into develop #10), and the publish-only shape (a release a person merged by hand) is a snippet inrelease-publish's README, with the checked-out commit astarget.develop; the publish: creating the tag, so a tag ruleset should block deletion and updates, not creation), that a personal access token or a GitHub App token does triggeron: releasewhilegithub.tokendoes not, that the caller template's environment with required reviewers is the human gate, and the one releasegithub.tokencannot create: one at a commit that changes a workflow file relative to the default branch, which afterrelease-mergenever happens (the published commit is the base branch's tip) and is the hand-merged publish's case. Therelease-mergeREADME and manifest point atrelease-publish; its code does not change here.develop-branch: ''has to be written in the caller: aworkflow_dispatchinput left empty takes its default, so the empty value cannot be passed through one. Said in therelease-mergeREADME.tests/actions/release-publish/release-publish.test.js, against the recorded Octokit and real files in a temporary directory. The recording fetch keeps a non-JSON body (an asset upload) as it was sent.How to test
mainanddevelop, copytemplates/workflows/release.ymlto.github/workflows/, with bothuses:pointing at this branch's commit, add a build step between the two actions and uncommentfiles:with the path it writes.release/x.y.zfrommain, bump the version files.puprclists on it (release-prepdoes this) and push.gh workflow run release.yml --ref release/x.y.z -f branch=release/x.y.z -f version=x.y.z(without--refthe first step fails and nothing is merged):mainanddevelopget the merges, the releasex.y.zexists with the file attached, and its tag points at the merge commit onmain.node --test(270 tests).docker run --rm -v "$PWD:/repo" -w /repo rhysd/actionlint:latest templates/workflows/release.yml.The steps were run on the two private test plugins, pinned to
e6cee72, this stack's head (the action code is unchanged sinceeab1115); the first two rows ran at that commit, the others ateab1115and9603173, whose action code is identical (only READMEs and the template changed since). The deploy callers of both and GiveWP'srelease-dashboard-deploy.ymlhave the shape ofrelease.yml:release-merge, the build, thenrelease-publish.develop:release-mergefails,release-publishnever runs, no tag and no releasemainforrelease/M26.split6: refused by the first step, nothing merged; the same dispatch with--refgoes throughgithub.tokenat the merge commitStack created with GitHub Stacks CLI • Give Feedback 💬
Summary by CodeRabbit
New Features
Documentation