Skip to content

feat: expose release-please outputs to calling workflows - #21

Merged
TheMeinerLP merged 1 commit into
mainfrom
feat/release-please-outputs
Aug 4, 2026
Merged

feat: expose release-please outputs to calling workflows#21
TheMeinerLP merged 1 commit into
mainfrom
feat/release-please-outputs

Conversation

@TheMeinerLP

Copy link
Copy Markdown
Contributor

release-please.yml runs 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:

publish:
  needs: release-please
  if: needs.release-please.outputs.release_created == 'true'

needs.release-please.outputs.release_created resolves 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 with outputs.version.

What this adds

release_created, releases_created, tag_name, version, sha, paths_released and prs.

The names are verified against the action's source, not assumed: action.yml declares no outputs: section at all — they are set dynamically through core.setOutput() in src/index.ts. Two things fall out of that:

  • tagName is deliberately published as tag_name (and notes as body, url as html_url) for backwards compatibility.
  • Per-package outputs on a multi-package manifest are prefixed with the package path (<path>--release_created). Those names are not knowable ahead of time, so a reusable workflow cannot declare them. That is documented on release_created, pointing at releases_created and paths_released instead.

Also in here

The README's release-please example 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:

setPathOutput(path, 'release_created', true)
if (key === 'tagName') key = 'tag_name'
core.setOutput('releases_created', ...)
core.setOutput('paths_released', ...)
core.setOutput('prs', ...)

Backwards compatible — this only adds outputs, no input or behaviour changes. Existing callers are unaffected.

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
TheMeinerLP merged commit 339e8a1 into main Aug 4, 2026
4 checks passed
@TheMeinerLP
TheMeinerLP deleted the feat/release-please-outputs branch August 4, 2026 14:34
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant