Repository navigation
ci: cut releases with release-please - #111
aryanjasala wants to merge 5 commits into
Conversation
Merge commits put subjects like "Merge pull request #n" on main, which release-please cannot read, and the repository moves to squash-only.
Pull request titles become the Conventional Commit subjects on main. release-please reads them, keeps a release pull request open that bumps .release-please-manifest.json and writes CHANGELOG.md, and merging it tags vX.Y.Z for Packagist and publishes the GitHub release. - release.yml and pr-title.yml (the PR title check is not required: the release pull request is opened with GITHUB_TOKEN and gets no runs) - changelog sections mapped to Keep a Changelog headings - the [Unreleased] heading goes, since release-please would insert new releases above it - maintainer docs, contributing checklist, PR and task templates follow the new flow, including which title type a contract change needs - the release config is export-ignored from the Composer dist
Dependabot picks its commit style from history unless told. Pinning chore(deps) keeps its titles valid for the PR title check and keeps dependency bumps out of release-please's releasable commits.
The title check's wip mode posts a commit status, which a fork pull request's read-only token can't write, so it now just passes or fails and needs only pull-requests: read. Both workflows use github.token. The security changelog section is gone: the title check doesn't accept a security type, so security fixes are titled fix(security).
There was a problem hiding this comment.
🟡 Changes recommended
The release guidance would remove required CI safeguards for Dependabot, while retaining those checks blocks token-created release PRs because their checks never run.
1 open issue
What changed in this PR
Replaces manual tagging with release-please so Conventional Commit PR titles drive version bumps, changelog entries, and GitHub releases for the Composer package.
Changes:
- Adds release automation and PR-title validation, starting from version
2.1.0. - Aligns Dependabot titles and merging with the squash-based release process.
- Updates contributor guidance and templates, removes the Unreleased heading, and excludes release configuration from Composer distributions.
| File | Description |
|---|---|
release-please-config.json |
Configures PHP releases and changelog sections. |
docs/maintainers.md |
Replaces manual release steps with the release-PR process. |
CONTRIBUTING.md |
Requires Conventional Commit PR titles instead of changelog edits. |
CHANGELOG.md |
Removes Unreleased and explains automated entries. |
.release-please-manifest.json |
Seeds the release version at 2.1.0. |
.github/workflows/release.yml |
Adds serialized release-please runs on main. |
.github/workflows/pr-title.yml |
Adds Conventional Commit title validation. |
.github/workflows/auto-merge.yml |
Uses squash merging for Dependabot updates. |
.github/pull_request_template.md |
Replaces the changelog checklist item with title guidance. |
.github/ISSUE_TEMPLATE/task.md |
Updates branching and PR guidance to target main. |
.github/dependabot.yml |
Sets dependency-update titles to the chore type. |
.gitattributes |
Excludes release-please configuration from distributions. |
Review effort: Balanced
| # request tags vX.Y.Z on main and publishes the GitHub release with the changelog entry as notes. | ||
| # | ||
| # The release pull request is opened with GITHUB_TOKEN, so GitHub starts no workflow runs on it | ||
| # (no tests, no PR title check). That is why neither check is a required status check. Switching |
There was a problem hiding this comment.
Fair. Nothing is required on main today (no branch protection, no required checks), so the two don't clash yet, but they would the day Test and Measure becomes required. fd43ef4 now says that in the workflow and names the ways out: a GitHub App token, which starts the release PR's checks, or a maintainer pushing an empty commit to the release branch. Leaving this open until we pick one.
auto-merge.yml expects the Test and Measure jobs to be required so a red Dependabot update can't merge, but a release pull request opened with GITHUB_TOKEN starts no runs and would wait on them forever. The release workflow's comment now says so and names the two ways out: a GitHub App token, or a maintainer pushing an empty commit to the release branch.
There was a problem hiding this comment.
🔵 Needs a closer look
Release automation depends on out-of-diff GitHub settings, including disabled Actions PR creation and squash-only merging with PR-title subjects, requiring maintainer confirmation and validation of the first release run.
Review effort: Balanced
Adi-ty
left a comment
Adi-ty
left a comment
There was a problem hiding this comment.
A couple of small doc fixes inline everything else looks good
|
|
||
| A `feat!:` also needs its entry in [upgrading.md](upgrading.md) in the same | ||
| pull request. | ||
| 3. When you want to release, review the release pull request: reword entries |
There was a problem hiding this comment.
Could you double-check the "reword entries in the release PR" advice here and in CHANGELOG? From what I understand, release-please rebuilds that branch on each run, so a hand edit may get overwritten on the next push and the release notes seem to come from the PR description rather than the file. If that's right, pointing at a BEGIN_COMMIT_OVERRIDE block in the merged PR's description might be safer.
|
|
||
| | Change | Title | | ||
| | --- | --- | | ||
| | Anything breaking in `inc/Contracts/` or in documented behaviour, including a new abstract method or a new interface method | `feat!:` (or a `BREAKING CHANGE:` footer), major | |
There was a problem hiding this comment.
The "(or a BREAKING CHANGE: footer)" part can be dropped as the squashed commit is built from the branch commit messages, so a footer written in the PR description wouldn't reach main.
What this PR does
Moves releases from the manual four-step tag procedure in
docs/maintainers.mdto release-please, the same flow rtCamp/wp-shared-workflows#45 sets up and rtCamp/plugin-skeleton-d and the One* plugins already use. PR titles become the Conventional Commit subjects onmain; release-please keeps one release pull request open that bumps the version and writesCHANGELOG.md, and merging it tagsvX.Y.Zfor Packagist and publishes the GitHub release.Closes
N/A
Changes
.github/workflows/release.ymlrunsgoogleapis/release-please-actionv5.0.0 (pinned by SHA) on every push tomain. Only that job getscontents,issuesandpull-requests: write; the workflow default iscontents: read. No alias-tag job: Packagist consumers pin^2.x, not a moving tag.release-please-config.json(release-type: php) maps commit types to the Keep a Changelog headings this changelog already uses:featAdded,fixFixed,perf/revert/buildChanged;docs,chore,ci,test,refactorandstyleare hidden and cut no release.composer.jsonhas noversionfield, so thephpstrategy leaves it alone..release-please-manifest.jsonstarts at2.1.0, the latest tag and GitHub release..github/workflows/pr-title.yml, the sameamannn/action-semantic-pull-requestcheck plugin-elementary already runs.CHANGELOG.mdloses the## [Unreleased]heading and its compare link. release-please inserts each release above the first heading that starts with[or a digit, so it would have put every new release above[Unreleased]. Old sections and their reference links are untouched.auto-merge.ymlsquash-merges Dependabot pull requests (--squashinstead of--merge);dependabot.ymlpins thechoreprefix so bumps stay valid titles and cut no release on their own.docs/maintainers.md"Releasing" now describes the release pull request and gives the title type for each kind of change, including that a new abstract or interface method isfeat!:and needs itsupgrading.mdentry in the same pull request.CONTRIBUTING.md, the PR template and the task issue template drop the[Unreleased]entry and therelease/<milestone>branch flow..gitattributesexport-ignores the two release-please files from the Composer dist.How I verified
actionlintandyamllintpass on the new and changed workflows; both JSON files parse.Changelogupdater against the newCHANGELOG.md: a sample9.8.7section lands directly above## [2.1.0].v2.1.0onmain: none, so the first run after merge opens no release pull request.Acceptance criteria
Runtime behavior
Releaserun passes and opens no release pull request (nothing releasable sincev2.1.0)feat:orfix:merge opens a release pull request with the right versionCode quality
actionlint,yamllintzero errorsHousekeeping
CHANGELOG.mdentry: release-please writes itReviewer notes
Repository settings to change when this merges (they are not in the diff):
PR_TITLE), and squash-only in the main ruleset's allowed merge methods too.GITHUB_TOKEN, which starts no workflow runs, so a required check would block every release. A GitHub App token inrelease.ymlwould fix that later.Other notes:
release-please creates lightweight tags, where the old procedure used annotated ones. Packagist reads both.
New sections use release-please's heading style,
## [2.2.0](compare-url) (date), so the file mixes it with the older## [2.1.0] - dateheadings. Nothing parses these headings today..github/release.yml(generated-notes categories) is no longer used for releases, since release-please writes the notes. Left in place; chore: add issue forms, CODEOWNERS, labels and release notes categories #110 edits it too.There is no
securitysection: the title check doesn't accept asecurity:type, so security fixes are titledfix(security):and land under Fixed.Repository settings before merging: "Allow GitHub Actions to create and approve pull requests" is off in this repository today, so release-please could not open its release PR. Turn it on (Settings, Actions, General), allow squash merging only, and set the squash commit title to the PR title.
The title check drops
wipmode: that mode posts a commit status, which a fork pull request's read-only token can't write. Keep "Validate PR title" out of the required checks: release PRs are opened withGITHUB_TOKEN, which starts no workflow runs.Overlap with chore: add issue forms, CODEOWNERS, labels and release notes categories #110: chore: add issue forms, CODEOWNERS, labels and release notes categories #110 adds a hand-written entry under
## [Unreleased]; this PR removes that heading, because release-please inserts each release above the first version heading and would leave anything under## [Unreleased]stranded. Whichever merges second drops chore: add issue forms, CODEOWNERS, labels and release notes categories #110's entry.Packagist picks up the
vX.Y.Ztag release-please creates through its GitHub webhook; GitHub's rule thatGITHUB_TOKENevents start no workflows doesn't apply to webhooks..github/release.yml(GitHub's generated-notes config) is left alone here to avoid a conflict with chore: add issue forms, CODEOWNERS, labels and release notes categories #110, which edits it; it is unused once release-please writes the notes and can go in a follow-up.