# semantic-release configuration.
#
# Run by hand from .gitea/workflows/release.yml, which has no push
# trigger: determine the version from the Conventional Commits since the
# last tag, write the changelog, push the tag, and create the Gitea
# release.  A release is a shipment rather than a merge, and the commits
# accumulate until someone says so -- this file needs to know nothing
# about that, because reading everything since the last tag is what it
# already did.
#
# `branches` is main and only main.  A `prerelease: true` channel is the
# obvious next edit here and is the one to think twice about: all four
# publishing workflows trigger on `v*`, which matches `v0.4.0-beta.1`.
# They carry a prerelease guard now, so the failure is a clean skip
# rather than a beta in a public tap -- but they are four separate files
# and this is the line that would turn them on.
#
# **There is no `@semantic-release/github` plugin here and there must not
# be.** Gitea's API is `/api/v1` and is not GitHub's surface. The Gitea
# community plugin (@saithodev/semantic-release-gitea) was considered and
# rejected: last published 2022, depends on got@10, and declares no peer
# dependency on semantic-release at all — i.e. untested against anything
# since v19, against a core now at v25. `exec` is first-party, current,
# and the Gitea-shaped part is one curl.
#
# The type list below is the one scripts/commit-check.sh enforces the
# grammar for — keep the two in step, or semantic-release will silently
# decline to release something the commit hook accepted.
branches:
  - main

plugins:
  # Analyze commits using conventional-commits preset.
  - - "@semantic-release/commit-analyzer"
    - preset: conventionalcommits
      releaseRules:
        - type: feat
          release: minor
        - type: fix
          release: patch
        - type: perf
          release: patch
        - type: refactor
          release: patch
        - type: revert
          release: patch
        - type: docs
          release: false
        - type: style
          release: false
        - type: chore
          release: false
        - type: ci
          release: false
        - type: test
          release: false
        - type: build
          release: false

  # Generate release notes from conventional commits.
  - - "@semantic-release/release-notes-generator"
    - preset: conventionalcommits
      presetConfig:
        types:
          - type: feat
            section: Features
          - type: fix
            section: Bug Fixes
          - type: perf
            section: Performance
          - type: refactor
            section: Refactoring
          - type: revert
            section: Reverts
          - type: docs
            section: Documentation
            hidden: true
          - type: chore
            section: Miscellaneous
            hidden: true
          - type: ci
            section: CI/CD
            hidden: true
          - type: test
            section: Tests
            hidden: true
          - type: build
            section: Build
            hidden: true

  # Render the notes to a file.
  #
  # **This plugin is here to carry the notes, not to maintain a document.**
  # It is how they reach the Gitea API *without being interpolated into a
  # shell command*: release notes are rendered commit messages — arbitrary
  # text carrying backticks, quotes and `$` — so templating
  # ${nextRelease.notes} into `publishCmd` would be a shell injection with
  # the commit log as its input. scripts/gitea-release.sh reads the top
  # section of this file instead, and the only thing interpolated below is
  # a semver string.
  #
  # The target is a gitignored build artifact rather than CHANGELOG.md,
  # because nothing commits it back — see below.
  - - "@semantic-release/changelog"
    - changelogFile: .release-notes.md
      changelogTitle: "# Release notes"

  # Create the Gitea release, whose body is that section.
  # `publish` runs after `prepare`, so the tag already exists by here.
  - - "@semantic-release/exec"
    - publishCmd: "./scripts/gitea-release.sh ${nextRelease.version}"

  # **There is deliberately no @semantic-release/git here.**
  #
  # `main` is a protected branch with `enable_push: false` and an empty
  # push whitelist, so a changelog commit-back would be rejected by the
  # pre-receive hook — *after* the tag had already been pushed, leaving a
  # tagged release the run then reported as failed. The alternative was to
  # whitelist the CI user, which weakens a protection someone set on
  # purpose and lets a bot push to main without passing the checks every
  # human PR has to.
  #
  # So the release page is the changelog. Tags are not protected, so the
  # tag push semantic-release does itself is unaffected. CHANGELOG.md in
  # the repo is a signpost to the releases page and is not written by any
  # of this; a file that claimed to be a changelog and silently stopped
  # updating would be worse than no file at all.