actions/changelog
Watch
2
0
Fork
You've already forked changelog
 0
Code Issues Pull requests Projects Releases 11 Packages Activity Actions
11 releases 12 tags
  • v1.0.0-rc1 b3151c7be7

    v1.0.0-rc1 Pre-release

    github-actions[bot] released this 2026-09-04 13:07:39 +00:00 | 72 commits to main since this release

    Added

    • Every check carries a name (heading-form, date-format, version-order,
      empty-entry, unknown-section), which appears in the finding and as the
      title of the workflow annotation.
    • -error, -warn and -off move a named check between severities, and
      -fail-on error|warning|never decides what turns the step red.
    • -list-checks prints the register of checks, and the README's table is
      generated from that same register.
    • date-order reports an entry dated later than the one above it, and
      date-future one dated later than today, both errors by default.
    • partial-link-refs requires a link reference definition on every versioned
      entry once any entry carries one, and says nothing about a document carrying
      none.
    • prerelease-entry reports a pre-release version heading. It encodes a policy
      rather than catching a defect, so it is the one check that is off by default.
    • Five outputs (valid, version, notes, already-tagged and latest-tag),
      written to $GITHUB_OUTPUT and printed on stdout for a local run. Every one
      is something the action read: latest-tag is the reference tag as the
      repository spells it, and nothing proposes a tag for version. notes is the
      entry body verbatim, under a delimiter drawn at random per value so a
      changelog cannot declare outputs of its own.
    • Four checks that read the repository's tags: no-git-tags reports a checkout
      whose tag history cannot be read, version-behind-tag reports a newest entry
      behind the reference tag, and release-entry-modified and
      prerelease-entry-modified report a released entry that has changed or gone
      since that tag.
    • One reference tag behind all four of those and behind latest-tag: the newest
      version tag reachable from HEAD, which is what git describe --tags names.
      Reachability takes no setting, because a tag on a branch the checkout is not on
      is never the right baseline, and it is what lets a maintained support line
      compare against its own last release. reference-tags: final|all decides
      whether a pre-release may serve as one, defaulting to final, so a release
      candidate staged above the newest entry stops reporting version-behind-tag.
      A repository that tags no pre-release reads the same under either setting.
    • examples/ carries one worked policy: a changelog written to it, the
      main-branch and pull-request workflow invocations that enforce it, and a
      deliberately broken copy. go test ./... validates both documents under the
      inputs those workflows carry.
    • This repository releases itself with its own action. A push to main runs the
      action against this changelog, and where it reports a version no tag carries,
      publishes the image, cuts the tag, creates the release from notes and moves
      the major tag for a final version. Nothing else cuts a tag here, and a tag
      pushed by hand is not a path. It is one workflow rather than two because a tag
      pushed with GITHUB_TOKEN triggers no workflow, so a cutting job and a job
      triggered by its tag would wait on each other forever.
    Downloads