Every release pull request this repository has ever opened is titled chore: release main — #1066, #1049, #598, #585, #566. The version it would publish is nowhere in the title, so a release pull request cannot be told apart from any other release pull request in a list, in a notification, or in the merge commit it becomes.
JorisJonkers-dev/deploy-kit titles the same pull request chore(main): release 0.2.0, and so does every other repository in that organisation: nix-config says chore(main): release 0.6.0, api-contract-checks says chore(main): release 1.1.0.
Why this one differs
release-please-config.json here sets two keys those repositories leave unset:
"separate-pull-requests": false,
"pull-request-title-pattern": "chore: release ${version}",In manifest.ts, separatePullRequests defaults to Object.keys(repositoryConfig).length === 1 — true for a single-package manifest, which this is. Setting it to false turns the merge plugin on anyway, and the merge plugin does not read pull-request-title-pattern. It reads group-pull-request-title-pattern, whose default is MANIFEST_PULL_REQUEST_TITLE_PATTERN = 'chore: release ${branch}'. Hence main where the version should be: the configured pattern is never consulted.
So the repository asks for the version in the title, and a second setting quietly makes that request unreachable.
The branch name stays as it is
release-please--branches--main is hard-coded in five workflow conditions across the two client repositories and in release.yml here, so it must not move. It does not: with package-name unset, a single-package release keeps BranchName.ofTargetBranch, which is the same string. nix-config and api-contract-checks are the evidence — right title, same branch.
The same two keys are set in ESA-Blueshell/brevo-client and ESA-Blueshell/discord-client, and nowhere else in either organisation.
Acceptance criteria
Every release pull request this repository has ever opened is titled
chore: release main— #1066, #1049, #598, #585, #566. The version it would publish is nowhere in the title, so a release pull request cannot be told apart from any other release pull request in a list, in a notification, or in the merge commit it becomes.JorisJonkers-dev/deploy-kittitles the same pull requestchore(main): release 0.2.0, and so does every other repository in that organisation:nix-configsayschore(main): release 0.6.0,api-contract-checkssayschore(main): release 1.1.0.Why this one differs
release-please-config.jsonhere sets two keys those repositories leave unset:In
manifest.ts,separatePullRequestsdefaults toObject.keys(repositoryConfig).length === 1— true for a single-package manifest, which this is. Setting it tofalseturns the merge plugin on anyway, and the merge plugin does not readpull-request-title-pattern. It readsgroup-pull-request-title-pattern, whose default isMANIFEST_PULL_REQUEST_TITLE_PATTERN = 'chore: release ${branch}'. Hencemainwhere the version should be: the configured pattern is never consulted.So the repository asks for the version in the title, and a second setting quietly makes that request unreachable.
The branch name stays as it is
release-please--branches--mainis hard-coded in five workflow conditions across the two client repositories and inrelease.ymlhere, so it must not move. It does not: withpackage-nameunset, a single-package release keepsBranchName.ofTargetBranch, which is the same string.nix-configandapi-contract-checksare the evidence — right title, same branch.The same two keys are set in
ESA-Blueshell/brevo-clientandESA-Blueshell/discord-client, and nowhere else in either organisation.Acceptance criteria
release-please--branches--main, so the workflow conditions that name it keep matching