v0.12.0 (2026-11-08)

💥 Breaking Change

Replace the ci action engine with the monochange ci CLI

Owner: @ifiokjr · Review: PR #122

The ci action is now a thin wrapper. Job rules live in the consumer's monochange.toml under [ci.jobs.*], and the CLI owns git diffing, provider calls, memory, learned rules, and verification.

This breaks the published ci contract:

• mode accepts decide (default), verify, or check. The old analytics and auth modes are now monochange ci analytics and monochange ci auth in the CLI.
• decide evaluates every configured job in one call and replaces the per-invocation job, paths, packages, unconditional*, max-skips-on-main, max-duration-minutes, duration-minutes, memory-path, suggestion, and verdict-class inputs with [ci] configuration.
• decide outputs decisions (JSON object of job id to boolean), affected-packages (JSON array), and run-all instead of decision, should-run, unconditional, reason, and the analytics counters.
• verify takes needs (${{ toJSON(needs) }}) and the gate's decisions output, then records each job outcome through the CLI. check takes workflow paths and validates the [ci] wiring.
• Workflows gate jobs with if: needs.gate.outputs.run-all == 'true' || fromJSON(needs.gate.outputs.decisions)['<job-id>'].

The action now pins monochange CLI 0.21.1, the first release that ships monochange ci. Re-pin the action SHA after this release to adopt it.

v0.11.1 (2026-11-07)

🚀 Feature

• add the monochange/actions/ci conditional CI gatekeeper, outcome verifier, and repo-scoped analytics action.
  Owner: @ifiokjr · Review: PR #120

v0.11.0 (2026-11-04)

💥 Breaking Change

Require fresh PR head checks after rebase or cherry-pick preparation before merging

Owner: @ifiokjr · Review: PR #113

Rebase and cherry-pick preparation now push the generated commit to the PR branch and return result: updated with merged: false. Wait for checks on the new head-sha, then run the action again to fast-forward that exact checked commit. A head already based on the base branch is fast-forwarded without replaying it again, including in cherry-pick mode.

Update workflows that expected preparation and merging in one run to handle updated and trigger the later merge run. Use a token that starts PR checks when the head is pushed. Post-update scripts and workflows dispatched on the base branch do not authorize an immediate merge. Dry runs now leave both branches unchanged.

Track the monochange 0.21.0 CLI release

Owner: @ifiokjr · Review: PR #102

The actions development and release tooling now resolves monochange 0.21.0, including Swift, CocoaPods and Gradle configuration support. This follows the breaking CLI release baseline. After the next maintainer-controlled actions release, pin its immutable commit SHA to adopt that CLI baseline; the existing action inputs remain supported.

🐛 Fixed

• Pin automatic CLI setup to the action release and verify archive integrity before execution.
  Owner: @ifiokjr · Review: PR #109
• Collect every legacy commit status before evaluating merge checks.
  Owner: @ifiokjr · Review: PR #111
• Require HTTPS without embedded credentials for hosted release requests.
  Owner: @ifiokjr · Review: PR #112
• Scope release-request GitHub tokens to the CLI child process instead of persisting them in later job steps.
  Owner: @ifiokjr · Review: PR #115
• read pnpm 12 multi-document lockfiles when binding the monochange CLI release.
  Owner: @ifiokjr · Review: PR #118
• keep the pnpm lockfile readable by GitHub's dependency graph.
  Owner: @ifiokjr · Review: PR #119
• Enforce merge authorization, check policy, and dry-run before branch updates and hooks. The merge action rejects unauthorized actors and blocked checks before creating its git workspace. Dry-run never rebases or pushes either branch, runs a post-update script, or dispatches a workflow. Post-update scripts receive only executable-path, locale, and temporary-directory variables instead of inheriting action inputs and job credentials.
  Owner: @ifiokjr · Review: PR #114

v0.10.1 (2026-10-21)

🚀 Feature

Create release commits and pull requests through monochange.dev

Owner: @ifiokjr · Review: PR #88

The new hosted-release variant prepares the release in the workflow, then lets monochange.dev create the release commit and the release pull request through the monochange GitHub App. The commit is verified by GitHub, the pull request triggers the repository's normal workflows, and the job needs no personal access token.

jobs:
  release-pr:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0
          fetch-tags: true
      - id: release
        uses: monochange/actions/hosted-release@v0
        with:
          release-command: release

• release-command runs the repository's own monochange.toml command with MONOCHANGE_RELEASE_BACKEND=hosted, so its Command steps and stage_all run as they do locally. It requires monochange 0.20.0 or newer. Without it, the action runs the built-in prepare, commit, and open release steps.

• github-token is passed to monochange as GITHUB_TOKEN. With contents: write, monochange 0.20.0 or newer uploads the release files as a git tree, so monochange.dev receives only the tree id.

• Install the monochange GitHub App on the repository and grant id-token: write; the action fails early with that instruction when the job cannot mint an OIDC token.

• Requires monochange 0.17.0 or newer. The action drives the CLI's hosted CommitRelease and OpenReleaseRequest backends instead of calling the endpoints itself.

• hosted-url (default https://monochange.dev) selects the deployment; the OIDC audience is its host.

• Outputs commit-sha, verified, head-branch, base-branch, pull-request-number, and pull-request-url, read back from GitHub. The step fails when GitHub does not verify the release commit.

• Failed hosted requests keep the CLI error and add the next step to take, such as installing the app (HTTP 404), clearing a release branch that moved (HTTP 409), or keeping workflow changes out of the release (HTTP 422).

📝 Changed

Keep change-classification comments specific to the pull request

Owner: @ifiokjr · Review: PR #75

The change-classification action now compares a pull request with the branch it targets and classifies the pull request head commit, so a stacked pull request no longer reports the changes of the branch below it.

• base defaults to origin/<base branch> from the pull_request event, and head defaults to the event's head commit. Each is used only when the checkout contains it; otherwise the action warns and keeps the previous behavior. Explicit inputs still win.
• The comment names the classified head commit and base commit.
• Findings seen only between the latest release and the base branch move to an "Unreleased changes already on <base> (not part of this pull request)" list and no longer count toward the package's findings.

Add the edited event, guarded by github.event.changes.base, so a retargeted pull request is classified again:

on:
  pull_request:
    types: [opened, synchronize, reopened, edited]
jobs:
  classify:
    if: ${{ github.event.action != 'edited' || github.event.changes.base }}

v0.10.0

💥 Breaking Change

Track the monochange CLI 0.15.0 release

Owner: @ifiokjr · Review: PR #73 · Related issues: #71

Bump the pinned @monochange/cli devDependency from 0.14.0 to 0.15.0. The action bundle is versioned independently of the CLI, so consumers that pin an action SHA can be running against a CLI whose interface moved underneath them; this release moves the action's major version in step with the CLI's.

monochange 0.15.0 is a breaking CLI release. monochange skill no longer forwards arguments to npx, pnpm dlx, or bunx, and MONOCHANGE_SKILL_SOURCE and MONOCHANGE_SKILL_RUNNER are removed in favor of monochange skill read <topic> and monochange skill install --dir <dir>. The change-classification report contract also advanced to schema_version 0.3, adding decision.pull_request_changes.

From this release on, a breaking change in monochange produces a breaking change in monochange/actions, so downstream pins move major versions together.

Verified locally: the pinned CLI reports 0.15.0, monochange next and step validate run against this repository's configuration, and the full pnpm all suite passes. The committed dist/ bundle is unchanged because the CLI is a development dependency.

🐛 Fixed

• Track the latest monochange CLI release. Bump the pinned @monochange/cli devDependency from 0.13.0 to 0.14.0. The repository's release automation runs pnpm exec monochange, so the pin decides which CLI refreshes the release pull request and validates changesets; this keeps it on the current published release. The committed dist/ bundle is unchanged because the CLI is a development dependency.
  Owner: @ifiokjr · Review: PR #71

v0.9.4

0.9.4 (2026-09-17)

🚀 Feature

Show whether a breaking change applies to main or the latest release

The change-classification action reads the new release_impact decision field and shows it next to the default-branch impact. A package that breaks only against main (its latest release never shipped the changed API) renders as breaking → additive (release) in the comment table, gets an informational callout naming the package, and appears in the job summary line. The new release-breaking output is true only when a package breaks against its latest release, so workflow routing can block those pulls without blocking refinements of unreleased APIs.

Reports from monochange versions without release_impact render exactly as before.

- id: classify
  uses: monochange/actions/change-classification@v0

- run: |
    if [[ "${{ steps.classify.outputs.release-breaking }}" == "true" ]]; then
      echo "A released API broke; a major changeset is required."
    fi

Owner: @ifiokjr · Review: PR #70

Skip classification on release pull requests and pass labels

The change-classification action reads the pull request's labels (or the new labels input) and passes them to monochange change classify via --label. Configure [changesets.classification].skip_labels in monochange.toml (default ["release"]) so the release pull request monochange opens is reported as skipped instead of classified: the command analyzes no packages, the action sets result: skipped, deletes any stale classification comment, and the job summary records the skip.

The parser also accepts the classification report's new contract: snake_case keys with schema_version as a major.minor string emitted by monochange_classification.

- uses: monochange/actions/change-classification@v0
  with:
    labels: release, automated

Owner: @ifiokjr · Review: PR #68

v0.9.3

0.9.3 (2026-09-14)

🚀 Feature

Release the action bundle with monochange

The repository now manages its own releases with monochange instead of hand-cut tags and releases. Every push to main refreshes a release pull request that bumps the tag-versioned package, and merging it creates the version tag, moves the v0.9 and v0 floating aliases, and publishes the GitHub release with generated notes.

Consumers keep pinning the same moving aliases:

- uses: monochange/actions@v0.9

A new changeset-policy check requires a .changeset/*.md entry when a pull request changes action behavior (TypeScript under src/ or any action.yml). Documentation, tests, and generated output are exempt, and the release and no-changeset-required labels skip the check.

Before: releases were cut by hand, so changes under src/ shipped with no required release note.

After:

# author a changeset with the CLI instead of writing frontmatter by hand
pnpm exec monochange run change --package actions --bump patch --reason "describe the fix"

The release pull request lists the planned version and consumes the pending changesets when it merges.

Owner: @ifiokjr · Review: PR #63

v0.9.2

Fixes

• change-classification now summarizes each package with breaking, minor, and patch finding counts (🔴 / 🟢 / ⚪) and collapses the individual findings and analysis warnings into <details> sections, so long reports stay scannable (#61, #62).
• Severity counts list only the categories a package actually has, so a package without breaking findings no longer shows a zero count (#62).
• Reports truncated at the comment size limit now close any dangling <details> block so the remaining report still renders (#61).

Docs

• Corrected the permissions documented for pull request comments (#60).

What's Changed

• feat(change-classification): summarize findings in collapsible package sections by @ifiokjr in #61
• fix(change-classification): mark severity counts with finding emoji by @ifiokjr in #62
• docs: correct the permissions required for pull request comments by @ifiokjr in #60

Full Changelog: v0.9.1...v0.9.2

v0.9.0

Features

• New monochange/actions/change-classification action that surfaces monochange change classify results as pull request comments (#58).

Fixes

• publish-packages now supports the stream-output input, so publish runs can stream step output instead of buffering it.

Security

• Updated action tooling dependencies to resolve known vulnerabilities.

Upgrade guide: from v0.8 to v0.9

Action inputs are unchanged, so most workflows only need to bump the action ref:

 - uses: monochange/actions@v0.8
 + uses: monochange/actions@v0.9

or pin the exact release:

- name: publish packages
  uses: monochange/actions@v0.9.0

v0.8.0

Breaking changes

• Updates the action wrappers for the MonoChange 0.8 CLI command API.
• Removes default usage of project-specific monochange run workflow aliases in favor of stable monochange step ... commands.
• Changeset policy now runs monochange step affected-packages instead of the old mc step:affected-packages command shape.

Upgrade guide: changeset-policy from v0.7 to v0.8

The changeset-policy action inputs are intentionally unchanged, so most workflows only need to bump the action ref:

 - uses: monochange/actions/changeset-policy@v0.7
 + uses: monochange/actions/changeset-policy@v0.8

or pin the exact release:

- name: run changeset policy
  uses: monochange/actions/changeset-policy@v0.8.0
  with:
    changed-paths: ${{ steps.changed.outputs.all_changed_files }}
    labels: ${{ join(github.event.pull_request.labels.*.name, ',') }}
    github-token: ${{ secrets.GITHUB_TOKEN }}

If your workflow provides MonoChange itself, make sure the command on PATH is now monochange from MonoChange 0.8.x:

 - setup-monochange: false # required `mc` on PATH in v0.7
 + setup-monochange: false # requires `monochange` on PATH in v0.8

If you pass a custom command, update it from mc to monochange:

 - setup-monochange: mc
 + setup-monochange: monochange

For projects using a development shell, point the action at the shell command that exposes MonoChange 0.8:

- name: run changeset policy
  uses: monochange/actions/changeset-policy@v0.8.0
  with:
    setup-monochange: devenv shell monochange
    changed-paths: ${{ steps.changed.outputs.all_changed_files }}
    labels: ${{ join(github.event.pull_request.labels.*.name, ',') }}

No input rename is required for changed-paths, labels, skip-labels, comment-on-failure, dry-run, or debug.

Added

• Adds dedicated action variants for check, release-preview, release-record, open-release-request, tag-release, publish-readiness, and publish-packages.
• Adds top-level path actions for the new variants while keeping root action dispatch via the name input.

Validation

• pnpm all passed before tagging.