feat: expose release-please outputs to calling workflows - #21
Merged
Conversation
The workflow ran the action but forwarded none of its outputs, so a caller
doing what the README already documents:
publish:
needs: release-please
if: needs.release-please.outputs.release_created == 'true'
got an empty string, the condition evaluated to false, and the follow-up
job never ran. The release was tagged and nothing was published - a
failure that only shows up at the next release, and looks like a
publishing problem rather than a wiring one.
Forwards release_created, releases_created, tag_name, version, sha,
paths_released and prs. Names verified against the action's source rather
than assumed: action.yml declares no outputs at all, they are set
dynamically via core.setOutput, and tagName is deliberately published as
tag_name for backwards compatibility.
The per-package values on a multi-package manifest are prefixed with the
package path, so their names are not knowable ahead of time and cannot be
declared here. That is documented on release_created, together with the
pointer to releases_created and paths_released.
The README's release-please example is updated to show the gating pattern
it was already assuming, and pinned to a release tag rather than the
unmaintained @v2 major alias.
TheMeinerLP
added a commit
to OneLiteFeatherNET/minestom-extensions
that referenced
this pull request
Aug 4, 2026
v2.2.0 through v2.4.0 only added workflows - docker-publish, gradle-docker-context and pr-lint - so nothing this repository calls changed behaviour. Checked against the workflows CHANGELOG. release-please stays inline for now: the reusable release-please.yml forwards none of the action's outputs, and the publish job is gated on `needs.release-please.outputs.release_created`. Switching over as-is would silently skip publishing on every release. OneLiteFeatherNET/workflows#21 adds those outputs; this repository can move once that is released.
TheMeinerLP
added a commit
to OneLiteFeatherNET/minestom-extensions
that referenced
this pull request
Aug 4, 2026
The inline job existed because the reusable one forwarded none of the action's outputs, and the publish job is gated on release_created. OneLiteFeatherNET/workflows#21 added them, released as v2.5.0, so the last inline piece of CI can go. All pins move to v2.5.0 in the same step, so every workflow in this repository references one version of the shared catalogue. The permissions block stays on the caller: a called workflow never holds more permissions than the calling one, so dropping contents/pull-requests write here would leave release-please unable to open its release PR. Checked against the tag rather than assumed: v2.5.0 exports release_created, and gradle-publish.yml@v2.5.0 still accepts java-version and java-distribution.
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.
release-please.ymlruns the action but forwards none of its outputs, so a caller cannot tell whether a release was actually cut.Why this matters
The README documents this pattern in two places, and it has never worked:
needs.release-please.outputs.release_createdresolves to an empty string, the condition is false, and the follow-up job is skipped. The release gets tagged and nothing is published — a failure that surfaces only at the next release, and looks like a publishing problem rather than a wiring one. The Docker example at line ~135 has the same issue withoutputs.version.What this adds
release_created,releases_created,tag_name,version,sha,paths_releasedandprs.The names are verified against the action's source, not assumed:
action.ymldeclares nooutputs:section at all — they are set dynamically throughcore.setOutput()insrc/index.ts. Two things fall out of that:tagNameis deliberately published astag_name(andnotesasbody,urlashtml_url) for backwards compatibility.<path>--release_created). Those names are not knowable ahead of time, so a reusable workflow cannot declare them. That is documented onrelease_created, pointing atreleases_createdandpaths_releasedinstead.Also in here
The README's
release-pleaseexample now shows the gating pattern it was already assuming, plus an output table. It was pinned to@v2— the major alias the pin strategy says is deliberately not maintained — so it now points at a release tag.Verification
YAML validated. The output names are cross-checked against
src/index.ts@v5:Backwards compatible — this only adds outputs, no input or behaviour changes. Existing callers are unaffected.