Outputs and an input that answer "is a release due?" and "is this tag the newest entry?" #30

New issue

Closed

opened 2026-10-04 14:38:15 +00:00 by mikluko · 1 comment

mikluko commented

2026-10-04 14:38:15 +00:00

(Migrated from github.com)

Problem

Two workflows consume the action, and each re-derives a verdict in shell from outputs the action already has.

A cut workflow, on a push to the trunk:

[ -n "$VERSION" ]         || skip "CHANGELOG.md names no version"
[ "$PRERELEASE" = false ] || skip "$VERSION is a prerelease"
[ "$TAGGED" = false ]     || skip "v$VERSION is already tagged"

A build workflow, on the pushed tag:

[ -n "$NEWEST" ] && [ "$REF_NAME" = "v$NEWEST" ] || fail "tag $REF_NAME is not the newest version"

The case is mikluko/nats-operator#21, and uptime-com/upreleaser's cut-release carries the same three guards.

Request

Output due (true or false): the newest entry names a version, no tag names it, and it is not a prerelease. An input due-prerelease, default false, lets a prerelease count as due.
Output due-reason: one sentence for the false case, such as "0.3.1 is already tagged", also written to the step summary.
Input expect: a version or a tag name. The action fails unless the newest entry names it, compared by the version it names, as tags already are, so v1.2.3 and 1.2.3 both match [1.2.3]. Empty means no expectation.

The names are suggestions.

What it leaves of the workflows

# cut
- id: changelog
  uses: mikluko/action-changelog@v1
- if: steps.changelog.outputs.due == 'true'
  env:
    VERSION: ${{ steps.changelog.outputs.version }}
  run: |
    git tag "v$VERSION"
    git push origin "refs/tags/v$VERSION"

# build, on the tag
- uses: mikluko/action-changelog@v1
  with:
    expect: ${{ github.ref_name }}

Not requested

The action still proposes and pushes no tag. The README keeps tag spelling with whatever cuts it, and these three additions only report what the action read.

Open question

Whether the action should also push the tag, behind an input with a tag format. It would remove the last two shell lines and reverse that position in the README.

## Problem Two workflows consume the action, and each re-derives a verdict in shell from outputs the action already has. A cut workflow, on a push to the trunk: ```sh [ -n "$VERSION" ] || skip "CHANGELOG.md names no version" [ "$PRERELEASE" = false ] || skip "$VERSION is a prerelease" [ "$TAGGED" = false ] || skip "v$VERSION is already tagged" ``` A build workflow, on the pushed tag: ```sh [ -n "$NEWEST" ] && [ "$REF_NAME" = "v$NEWEST" ] || fail "tag $REF_NAME is not the newest version" ``` The case is mikluko/nats-operator#21, and `uptime-com/upreleaser`'s `cut-release` carries the same three guards. ## Request 1. Output `due` (`true` or `false`): the newest entry names a version, no tag names it, and it is not a prerelease. An input `due-prerelease`, default `false`, lets a prerelease count as due. 2. Output `due-reason`: one sentence for the `false` case, such as "0.3.1 is already tagged", also written to the step summary. 3. Input `expect`: a version or a tag name. The action fails unless the newest entry names it, compared by the version it names, as tags already are, so `v1.2.3` and `1.2.3` both match `[1.2.3]`. Empty means no expectation. The names are suggestions. ## What it leaves of the workflows ```yaml # cut - id: changelog uses: mikluko/action-changelog@v1 - if: steps.changelog.outputs.due == 'true' env: VERSION: ${{ steps.changelog.outputs.version }} run: | git tag "v$VERSION" git push origin "refs/tags/v$VERSION" # build, on the tag - uses: mikluko/action-changelog@v1 with: expect: ${{ github.ref_name }} ``` ## Not requested The action still proposes and pushes no tag. The README keeps tag spelling with whatever cuts it, and these three additions only report what the action read. ## Open question Whether the action should also push the tag, behind an input with a tag format. It would remove the last two shell lines and reverse that position in the README.

mikluko commented

2026-10-04 14:54:21 +00:00

(Migrated from github.com)

Partially implemented in #31.

Implemented: the due and due-reason outputs and the due-prerelease input (items 1 and 2). One addition to what was asked: due is false where the repository's tags cannot be read.

Won't fix: the expect input (item 3). As a bare input it would fail outside the register, with no annotation and no say for fail-on, and it fits only the trunk ceremony: on a candidate tag the entry and the tag differ by design. A workflow building on a tag keeps its own comparison of the ref against version.

The open question, whether the action should push the tag, was not taken up.

Partially implemented in #31. **Implemented:** the `due` and `due-reason` outputs and the `due-prerelease` input (items 1 and 2). One addition to what was asked: `due` is `false` where the repository's tags cannot be read. **Won't fix:** the `expect` input (item 3). As a bare input it would fail outside the register, with no annotation and no say for `fail-on`, and it fits only the trunk ceremony: on a candidate tag the entry and the tag differ by design. A workflow building on a tag keeps its own comparison of the ref against `version`. The open question, whether the action should push the tag, was not taken up.