Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions .github/workflows/release-please.yml
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,11 @@ on:
description: 'Optional version to force, for example 1.10.0. Leave empty to use Conventional Commits.'
type: string
required: false
force_release:
description: 'Force a release workflow by creating one minimal fix commit when no release-worthy commits are detected.'
type: boolean
required: false
default: false

permissions:
contents: write
Expand All @@ -29,6 +34,21 @@ jobs:
token: ${{ secrets.GITHUB_TOKEN }}
release-as: ${{ inputs.release_as || '' }}

- name: Create release trigger commit for manual forced release
if: ${{ github.event_name == 'workflow_dispatch' && inputs.force_release == true && steps.release.outputs.release_created == 'false' }}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Treat an unset release output as no release

When release-please-action v4 creates no release, the root release_created output is unset rather than the literal string 'false'. Consequently, a manual dispatch with force_release=true skips this step in exactly the no-release case it is intended to handle; test the output for falsiness or use the aggregate releases_created output instead.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Check for a release PR before adding the trigger commit

On a forced dispatch where releasable commits already exist, release-please can create or update a release PR without publishing a GitHub release, so release_created remains false or unset. Once the output comparison above is corrected, this fallback will therefore add a fabricated fix commit even though release-worthy commits were detected, contrary to the input's stated behavior; gate the fallback on whether a release PR was produced or updated rather than only on release publication.

Useful? React with 👍 / 👎.

run: |
set -euo pipefail
if [ -z "${{ inputs.release_as }}" ]; then
echo "force_release requested, but release_as is required" >&2
exit 1
fi
git config user.name "github-actions[bot]"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Check out the repository before running git

When this forced step does run, the only actions/checkout invocation in the workflow occurs later and is guarded by release_created. The release-please action uses the GitHub API and does not populate GITHUB_WORKSPACE, so this first local git config runs outside a repository and exits under set -e before the trigger commit can be created.

Useful? React with 👍 / 👎.

git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
git checkout main
git reset --hard origin/main
git commit --allow-empty -m "fix(action): trigger manual release ${{ inputs.release_as }}"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Preserve the requested version for the follow-up release

If the push is changed so that it does trigger another run, that run is a push event and therefore has no inputs.release_as; the new commit is simply a conventional fix commit, which requests a patch bump. Thus a forced non-patch version such as 2.0.0 would instead produce the next patch release. Encode the requested version in a Release-As footer or otherwise pass it to the run that processes this commit.

Useful? React with 👍 / 👎.

git push origin HEAD:main

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Do not rely on a GITHUB_TOKEN push to rerun the workflow

After this commit is pushed, the release-please action has already completed, so another workflow run is required to process the new fix commit. A push authenticated with the workflow's GITHUB_TOKEN does not trigger another push workflow, however, so even after adding the missing checkout this dispatch will stop after creating the commit and never create the requested release; rerun release-please in this job or use credentials that can trigger the follow-up workflow.

Useful? React with 👍 / 👎.


# Move the moving major tag here rather than in release-major-tag.yml: a
# release created with GITHUB_TOKEN does NOT trigger other workflows, so the
# `release: published` listener wouldn't fire for release-please releases.
Expand Down
Loading