ci: drop package-name so the grouped release PR resolves its component

[nadeem4]

Release-please has refused to create the v0.1.0 tag across three cycles. It finds the correct merged release PR (#67) and then aborts:

✔ Merging 1 pull requests
⚠ pullRequestTitlePattern miss the part of '${scope}'
⚠ pullRequestTitlePattern miss the part of '${component}'
⚠ pullRequestTitlePattern miss the part of '${version}'
❯ Found pull request #67: 'chore: release main'
⚠ There are untagged, merged release PRs outstanding - aborting

That abort is a consequence, not the cause. Earlier in the same run, in the Building releases phase, is the real failure:

✔ Building release for path: .
⚠ PR component: undefined does not match configured component: nl2sql-engine

Root cause: getComponent() and getBranchComponent() disagree

release-please v17.3.0, src/strategies/base.ts:

asyncgetComponent(){if(!this.includeComponentInTag)return''; ... }// -> ""asyncgetBranchComponent(){returnthis.component|| ...;}// -> "nl2sql-engine"

getBranchComponent() ignores include-component-in-tag; getComponent() honours it. package-name: "nl2sql-engine" is what populated this.component.

Meanwhile, because separate-pull-requests is false, the Merge plugin names the grouped release branch itself:

headRefName: this.headBranchName??BranchName.ofTargetBranch(this.targetBranch).toString(),

giving release-please--branches--main — no component in it. On the way back, buildRelease compares branchName.component (undefined) against getBranchComponent() (nl2sql-engine), mismatches, and returns without building a release. No tag, ever.

This only bites with exactly one root package, grouping on, package-name set, and include-component-in-tag: false.

Verification

Driven against this repo and PR #67's real body through strategy.buildReleases() on release-please 17.3.0 — the exact version CI runs:

Config	Merged PR title	Result
current	chore: release main	NO RELEASE — PR component: undefined does not match configured component: nl2sql-engine (reproduces CI exactly)
current + group-pull-request-title-pattern	chore: release 0.1.0	NO RELEASE — same component mismatch
this PR (no package-name)	chore: release main	tag=v0.1.0 ✅
no package-name + title pattern	chore: release main	NO RELEASE — Bad pull request title

Row 2 is the important one: changing the title pattern does not fix this. Row 4 is why it must not be changed — see below.

The title-pattern warnings are noise

pullRequestTitlePattern miss the part of '${...}' fires unconditionally whenever a pattern omits a placeholder. The built-in grouped-PR default is chore: release ${branch} (src/manifest.ts:295), which omits all three, so these warnings appear on healthy runs too.

A title without ${version} is not fatal. Release-please falls back to the PR body, whose <summary>0.1.0</summary> block carries the version — the documentation says it parses it "either via the pull request title or body format".

Do not strip autorelease: pending from #67

#67's label must be left alone, or 0.1.0 is stranded permanently.

With this fix, #67 tags v0.1.0 from its body, release-please swaps its label to autorelease: tagged, and the abort clears on its own. publish_pypi.yaml then fires on v0.1.0 (tags: ["v*"] — tag naming is unaffected, verified v0.1.0).

Stripping the label instead makes release-please forget #67 entirely. The manifest already reads 0.1.0, so the next release PR would bump 0.1.0 → 0.2.0 and 0.1.0 would never be published.

Why removing package-name is safe

It was inert apart from the bug. src/strategies/python.ts sets projectName = pyProject.name, so the __init__.py and changelog.json updaters read the root pyproject.toml — whose name is nl2sql-monorepo, not nl2sql-engine. The set of files release-please updates is unchanged, and getComponent() was already "".

Also in this PR

A troubleshooting section in docs/development/releasing.md recording both traps with their exact greppable symptoms: this component mismatch (including that the pullRequestTitlePattern warnings are not the cause — that misdiagnosis cost a cycle), and that the manifest holds the last released version and must be seeded below the first target.

No version, CHANGELOG.md, or .release-please-manifest.json was touched. Unit 231 passed, 1 skipped, 47 deselected and key-free integration 28 passed, both twice; mkdocs build --strict clean.

[nadeem4]

Release-please has refused to create the v0.1.0 tag across three cycles. It finds the correct merged release PR (#67) and then aborts:

✔ Merging 1 pull requests
⚠ pullRequestTitlePattern miss the part of '${scope}'
⚠ pullRequestTitlePattern miss the part of '${component}'
⚠ pullRequestTitlePattern miss the part of '${version}'
❯ Found pull request #67: 'chore: release main'
⚠ There are untagged, merged release PRs outstanding - aborting

That abort is a consequence, not the cause. Earlier in the same run, in the Building releases phase, is the real failure:

✔ Building release for path: .
⚠ PR component: undefined does not match configured component: nl2sql-engine

Root cause: getComponent() and getBranchComponent() disagree

release-please v17.3.0, src/strategies/base.ts:

asyncgetComponent(){if(!this.includeComponentInTag)return''; ... }// -> ""asyncgetBranchComponent(){returnthis.component|| ...;}// -> "nl2sql-engine"

getBranchComponent() ignores include-component-in-tag; getComponent() honours it. package-name: "nl2sql-engine" is what populated this.component.

Meanwhile, because separate-pull-requests is false, the Merge plugin names the grouped release branch itself:

headRefName: this.headBranchName??BranchName.ofTargetBranch(this.targetBranch).toString(),

giving release-please--branches--main — no component in it. On the way back, buildRelease compares branchName.component (undefined) against getBranchComponent() (nl2sql-engine), mismatches, and returns without building a release. No tag, ever.

This only bites with exactly one root package, grouping on, package-name set, and include-component-in-tag: false.

Verification

Driven against this repo and PR #67's real body through strategy.buildReleases() on release-please 17.3.0 — the exact version CI runs:

Config	Merged PR title	Result
current	chore: release main	NO RELEASE — PR component: undefined does not match configured component: nl2sql-engine (reproduces CI exactly)
current + group-pull-request-title-pattern	chore: release 0.1.0	NO RELEASE — same component mismatch
this PR (no package-name)	chore: release main	tag=v0.1.0 ✅
no package-name + title pattern	chore: release main	NO RELEASE — Bad pull request title

Row 2 is the important one: changing the title pattern does not fix this. Row 4 is why it must not be changed — see below.

The title-pattern warnings are noise

pullRequestTitlePattern miss the part of '${...}' fires unconditionally whenever a pattern omits a placeholder. The built-in grouped-PR default is chore: release ${branch} (src/manifest.ts:295), which omits all three, so these warnings appear on healthy runs too.

A title without ${version} is not fatal. Release-please falls back to the PR body, whose <summary>0.1.0</summary> block carries the version — the documentation says it parses it "either via the pull request title or body format".

Do not strip autorelease: pending from #67

#67's label must be left alone, or 0.1.0 is stranded permanently.

With this fix, #67 tags v0.1.0 from its body, release-please swaps its label to autorelease: tagged, and the abort clears on its own. publish_pypi.yaml then fires on v0.1.0 (tags: ["v*"] — tag naming is unaffected, verified v0.1.0).

Stripping the label instead makes release-please forget #67 entirely. The manifest already reads 0.1.0, so the next release PR would bump 0.1.0 → 0.2.0 and 0.1.0 would never be published.

Why removing package-name is safe

It was inert apart from the bug. src/strategies/python.ts sets projectName = pyProject.name, so the __init__.py and changelog.json updaters read the root pyproject.toml — whose name is nl2sql-monorepo, not nl2sql-engine. The set of files release-please updates is unchanged, and getComponent() was already "".

Also in this PR

A troubleshooting section in docs/development/releasing.md recording both traps with their exact greppable symptoms: this component mismatch (including that the pullRequestTitlePattern warnings are not the cause — that misdiagnosis cost a cycle), and that the manifest holds the last released version and must be seeded below the first target.

No version, CHANGELOG.md, or .release-please-manifest.json was touched. Unit 231 passed, 1 skipped, 47 deselected and key-free integration 28 passed, both twice; mkdocs build --strict clean.

[nadeem4]

Release-please has refused to create the v0.1.0 tag across three cycles. It finds the correct merged release PR (#67) and then aborts:

✔ Merging 1 pull requests
⚠ pullRequestTitlePattern miss the part of '${scope}'
⚠ pullRequestTitlePattern miss the part of '${component}'
⚠ pullRequestTitlePattern miss the part of '${version}'
❯ Found pull request #67: 'chore: release main'
⚠ There are untagged, merged release PRs outstanding - aborting

That abort is a consequence, not the cause. Earlier in the same run, in the Building releases phase, is the real failure:

✔ Building release for path: .
⚠ PR component: undefined does not match configured component: nl2sql-engine

Root cause: getComponent() and getBranchComponent() disagree

release-please v17.3.0, src/strategies/base.ts:

asyncgetComponent(){if(!this.includeComponentInTag)return''; ... }// -> ""asyncgetBranchComponent(){returnthis.component|| ...;}// -> "nl2sql-engine"

getBranchComponent() ignores include-component-in-tag; getComponent() honours it. package-name: "nl2sql-engine" is what populated this.component.

Meanwhile, because separate-pull-requests is false, the Merge plugin names the grouped release branch itself:

headRefName: this.headBranchName??BranchName.ofTargetBranch(this.targetBranch).toString(),

giving release-please--branches--main — no component in it. On the way back, buildRelease compares branchName.component (undefined) against getBranchComponent() (nl2sql-engine), mismatches, and returns without building a release. No tag, ever.

This only bites with exactly one root package, grouping on, package-name set, and include-component-in-tag: false.

Verification

Driven against this repo and PR #67's real body through strategy.buildReleases() on release-please 17.3.0 — the exact version CI runs:

Config	Merged PR title	Result
current	chore: release main	NO RELEASE — PR component: undefined does not match configured component: nl2sql-engine (reproduces CI exactly)
current + group-pull-request-title-pattern	chore: release 0.1.0	NO RELEASE — same component mismatch
this PR (no package-name)	chore: release main	tag=v0.1.0 ✅
no package-name + title pattern	chore: release main	NO RELEASE — Bad pull request title

Row 2 is the important one: changing the title pattern does not fix this. Row 4 is why it must not be changed — see below.

The title-pattern warnings are noise

pullRequestTitlePattern miss the part of '${...}' fires unconditionally whenever a pattern omits a placeholder. The built-in grouped-PR default is chore: release ${branch} (src/manifest.ts:295), which omits all three, so these warnings appear on healthy runs too.

A title without ${version} is not fatal. Release-please falls back to the PR body, whose <summary>0.1.0</summary> block carries the version — the documentation says it parses it "either via the pull request title or body format".

Do not strip autorelease: pending from #67

#67's label must be left alone, or 0.1.0 is stranded permanently.

With this fix, #67 tags v0.1.0 from its body, release-please swaps its label to autorelease: tagged, and the abort clears on its own. publish_pypi.yaml then fires on v0.1.0 (tags: ["v*"] — tag naming is unaffected, verified v0.1.0).

Stripping the label instead makes release-please forget #67 entirely. The manifest already reads 0.1.0, so the next release PR would bump 0.1.0 → 0.2.0 and 0.1.0 would never be published.

Why removing package-name is safe

It was inert apart from the bug. src/strategies/python.ts sets projectName = pyProject.name, so the __init__.py and changelog.json updaters read the root pyproject.toml — whose name is nl2sql-monorepo, not nl2sql-engine. The set of files release-please updates is unchanged, and getComponent() was already "".

Also in this PR

A troubleshooting section in docs/development/releasing.md recording both traps with their exact greppable symptoms: this component mismatch (including that the pullRequestTitlePattern warnings are not the cause — that misdiagnosis cost a cycle), and that the manifest holds the last released version and must be seeded below the first target.

No version, CHANGELOG.md, or .release-please-manifest.json was touched. Unit 231 passed, 1 skipped, 47 deselected and key-free integration 28 passed, both twice; mkdocs build --strict clean.

[nadeem4]

Release-please has refused to create the v0.1.0 tag across three cycles. It finds the correct merged release PR (#67) and then aborts:

✔ Merging 1 pull requests
⚠ pullRequestTitlePattern miss the part of '${scope}'
⚠ pullRequestTitlePattern miss the part of '${component}'
⚠ pullRequestTitlePattern miss the part of '${version}'
❯ Found pull request #67: 'chore: release main'
⚠ There are untagged, merged release PRs outstanding - aborting

That abort is a consequence, not the cause. Earlier in the same run, in the Building releases phase, is the real failure:

✔ Building release for path: .
⚠ PR component: undefined does not match configured component: nl2sql-engine

Root cause: getComponent() and getBranchComponent() disagree

release-please v17.3.0, src/strategies/base.ts:

asyncgetComponent(){if(!this.includeComponentInTag)return''; ... }// -> ""asyncgetBranchComponent(){returnthis.component|| ...;}// -> "nl2sql-engine"

getBranchComponent() ignores include-component-in-tag; getComponent() honours it. package-name: "nl2sql-engine" is what populated this.component.

Meanwhile, because separate-pull-requests is false, the Merge plugin names the grouped release branch itself:

headRefName: this.headBranchName??BranchName.ofTargetBranch(this.targetBranch).toString(),

giving release-please--branches--main — no component in it. On the way back, buildRelease compares branchName.component (undefined) against getBranchComponent() (nl2sql-engine), mismatches, and returns without building a release. No tag, ever.

This only bites with exactly one root package, grouping on, package-name set, and include-component-in-tag: false.

Verification

Driven against this repo and PR #67's real body through strategy.buildReleases() on release-please 17.3.0 — the exact version CI runs:

Config	Merged PR title	Result
current	chore: release main	NO RELEASE — PR component: undefined does not match configured component: nl2sql-engine (reproduces CI exactly)
current + group-pull-request-title-pattern	chore: release 0.1.0	NO RELEASE — same component mismatch
this PR (no package-name)	chore: release main	tag=v0.1.0 ✅
no package-name + title pattern	chore: release main	NO RELEASE — Bad pull request title

Row 2 is the important one: changing the title pattern does not fix this. Row 4 is why it must not be changed — see below.

The title-pattern warnings are noise

pullRequestTitlePattern miss the part of '${...}' fires unconditionally whenever a pattern omits a placeholder. The built-in grouped-PR default is chore: release ${branch} (src/manifest.ts:295), which omits all three, so these warnings appear on healthy runs too.

A title without ${version} is not fatal. Release-please falls back to the PR body, whose <summary>0.1.0</summary> block carries the version — the documentation says it parses it "either via the pull request title or body format".

Do not strip autorelease: pending from #67

#67's label must be left alone, or 0.1.0 is stranded permanently.

With this fix, #67 tags v0.1.0 from its body, release-please swaps its label to autorelease: tagged, and the abort clears on its own. publish_pypi.yaml then fires on v0.1.0 (tags: ["v*"] — tag naming is unaffected, verified v0.1.0).

Stripping the label instead makes release-please forget #67 entirely. The manifest already reads 0.1.0, so the next release PR would bump 0.1.0 → 0.2.0 and 0.1.0 would never be published.

Why removing package-name is safe

It was inert apart from the bug. src/strategies/python.ts sets projectName = pyProject.name, so the __init__.py and changelog.json updaters read the root pyproject.toml — whose name is nl2sql-monorepo, not nl2sql-engine. The set of files release-please updates is unchanged, and getComponent() was already "".

Also in this PR

A troubleshooting section in docs/development/releasing.md recording both traps with their exact greppable symptoms: this component mismatch (including that the pullRequestTitlePattern warnings are not the cause — that misdiagnosis cost a cycle), and that the manifest holds the last released version and must be seeded below the first target.

No version, CHANGELOG.md, or .release-please-manifest.json was touched. Unit 231 passed, 1 skipped, 47 deselected and key-free integration 28 passed, both twice; mkdocs build --strict clean.

[nadeem4]

Release-please has refused to create the v0.1.0 tag across three cycles. It finds the correct merged release PR (#67) and then aborts:

✔ Merging 1 pull requests
⚠ pullRequestTitlePattern miss the part of '${scope}'
⚠ pullRequestTitlePattern miss the part of '${component}'
⚠ pullRequestTitlePattern miss the part of '${version}'
❯ Found pull request #67: 'chore: release main'
⚠ There are untagged, merged release PRs outstanding - aborting

That abort is a consequence, not the cause. Earlier in the same run, in the Building releases phase, is the real failure:

✔ Building release for path: .
⚠ PR component: undefined does not match configured component: nl2sql-engine

Root cause: getComponent() and getBranchComponent() disagree

release-please v17.3.0, src/strategies/base.ts:

asyncgetComponent(){if(!this.includeComponentInTag)return''; ... }// -> ""asyncgetBranchComponent(){returnthis.component|| ...;}// -> "nl2sql-engine"

getBranchComponent() ignores include-component-in-tag; getComponent() honours it. package-name: "nl2sql-engine" is what populated this.component.

Meanwhile, because separate-pull-requests is false, the Merge plugin names the grouped release branch itself:

headRefName: this.headBranchName??BranchName.ofTargetBranch(this.targetBranch).toString(),

giving release-please--branches--main — no component in it. On the way back, buildRelease compares branchName.component (undefined) against getBranchComponent() (nl2sql-engine), mismatches, and returns without building a release. No tag, ever.

This only bites with exactly one root package, grouping on, package-name set, and include-component-in-tag: false.

Verification

Driven against this repo and PR #67's real body through strategy.buildReleases() on release-please 17.3.0 — the exact version CI runs:

Config	Merged PR title	Result
current	chore: release main	NO RELEASE — PR component: undefined does not match configured component: nl2sql-engine (reproduces CI exactly)
current + group-pull-request-title-pattern	chore: release 0.1.0	NO RELEASE — same component mismatch
this PR (no package-name)	chore: release main	tag=v0.1.0 ✅
no package-name + title pattern	chore: release main	NO RELEASE — Bad pull request title

Row 2 is the important one: changing the title pattern does not fix this. Row 4 is why it must not be changed — see below.

The title-pattern warnings are noise

pullRequestTitlePattern miss the part of '${...}' fires unconditionally whenever a pattern omits a placeholder. The built-in grouped-PR default is chore: release ${branch} (src/manifest.ts:295), which omits all three, so these warnings appear on healthy runs too.

A title without ${version} is not fatal. Release-please falls back to the PR body, whose <summary>0.1.0</summary> block carries the version — the documentation says it parses it "either via the pull request title or body format".

Do not strip autorelease: pending from #67

#67's label must be left alone, or 0.1.0 is stranded permanently.

With this fix, #67 tags v0.1.0 from its body, release-please swaps its label to autorelease: tagged, and the abort clears on its own. publish_pypi.yaml then fires on v0.1.0 (tags: ["v*"] — tag naming is unaffected, verified v0.1.0).

Stripping the label instead makes release-please forget #67 entirely. The manifest already reads 0.1.0, so the next release PR would bump 0.1.0 → 0.2.0 and 0.1.0 would never be published.

Why removing package-name is safe

It was inert apart from the bug. src/strategies/python.ts sets projectName = pyProject.name, so the __init__.py and changelog.json updaters read the root pyproject.toml — whose name is nl2sql-monorepo, not nl2sql-engine. The set of files release-please updates is unchanged, and getComponent() was already "".

Also in this PR

A troubleshooting section in docs/development/releasing.md recording both traps with their exact greppable symptoms: this component mismatch (including that the pullRequestTitlePattern warnings are not the cause — that misdiagnosis cost a cycle), and that the manifest holds the last released version and must be seeded below the first target.

No version, CHANGELOG.md, or .release-please-manifest.json was touched. Unit 231 passed, 1 skipped, 47 deselected and key-free integration 28 passed, both twice; mkdocs build --strict clean.

[nadeem4]

Release-please has refused to create the v0.1.0 tag across three cycles. It finds the correct merged release PR (#67) and then aborts:

✔ Merging 1 pull requests
⚠ pullRequestTitlePattern miss the part of '${scope}'
⚠ pullRequestTitlePattern miss the part of '${component}'
⚠ pullRequestTitlePattern miss the part of '${version}'
❯ Found pull request #67: 'chore: release main'
⚠ There are untagged, merged release PRs outstanding - aborting

That abort is a consequence, not the cause. Earlier in the same run, in the Building releases phase, is the real failure:

✔ Building release for path: .
⚠ PR component: undefined does not match configured component: nl2sql-engine

Root cause: getComponent() and getBranchComponent() disagree

release-please v17.3.0, src/strategies/base.ts:

asyncgetComponent(){if(!this.includeComponentInTag)return''; ... }// -> ""asyncgetBranchComponent(){returnthis.component|| ...;}// -> "nl2sql-engine"

getBranchComponent() ignores include-component-in-tag; getComponent() honours it. package-name: "nl2sql-engine" is what populated this.component.

Meanwhile, because separate-pull-requests is false, the Merge plugin names the grouped release branch itself:

headRefName: this.headBranchName??BranchName.ofTargetBranch(this.targetBranch).toString(),

giving release-please--branches--main — no component in it. On the way back, buildRelease compares branchName.component (undefined) against getBranchComponent() (nl2sql-engine), mismatches, and returns without building a release. No tag, ever.

This only bites with exactly one root package, grouping on, package-name set, and include-component-in-tag: false.

Verification

Driven against this repo and PR #67's real body through strategy.buildReleases() on release-please 17.3.0 — the exact version CI runs:

Config	Merged PR title	Result
current	chore: release main	NO RELEASE — PR component: undefined does not match configured component: nl2sql-engine (reproduces CI exactly)
current + group-pull-request-title-pattern	chore: release 0.1.0	NO RELEASE — same component mismatch
this PR (no package-name)	chore: release main	tag=v0.1.0 ✅
no package-name + title pattern	chore: release main	NO RELEASE — Bad pull request title

Row 2 is the important one: changing the title pattern does not fix this. Row 4 is why it must not be changed — see below.

The title-pattern warnings are noise

pullRequestTitlePattern miss the part of '${...}' fires unconditionally whenever a pattern omits a placeholder. The built-in grouped-PR default is chore: release ${branch} (src/manifest.ts:295), which omits all three, so these warnings appear on healthy runs too.

A title without ${version} is not fatal. Release-please falls back to the PR body, whose <summary>0.1.0</summary> block carries the version — the documentation says it parses it "either via the pull request title or body format".

Do not strip autorelease: pending from #67

#67's label must be left alone, or 0.1.0 is stranded permanently.

With this fix, #67 tags v0.1.0 from its body, release-please swaps its label to autorelease: tagged, and the abort clears on its own. publish_pypi.yaml then fires on v0.1.0 (tags: ["v*"] — tag naming is unaffected, verified v0.1.0).

Stripping the label instead makes release-please forget #67 entirely. The manifest already reads 0.1.0, so the next release PR would bump 0.1.0 → 0.2.0 and 0.1.0 would never be published.

Why removing package-name is safe

It was inert apart from the bug. src/strategies/python.ts sets projectName = pyProject.name, so the __init__.py and changelog.json updaters read the root pyproject.toml — whose name is nl2sql-monorepo, not nl2sql-engine. The set of files release-please updates is unchanged, and getComponent() was already "".

Also in this PR

A troubleshooting section in docs/development/releasing.md recording both traps with their exact greppable symptoms: this component mismatch (including that the pullRequestTitlePattern warnings are not the cause — that misdiagnosis cost a cycle), and that the manifest holds the last released version and must be seeded below the first target.

No version, CHANGELOG.md, or .release-please-manifest.json was touched. Unit 231 passed, 1 skipped, 47 deselected and key-free integration 28 passed, both twice; mkdocs build --strict clean.

[nadeem4]

Release-please has refused to create the v0.1.0 tag across three cycles. It finds the correct merged release PR (#67) and then aborts:

✔ Merging 1 pull requests
⚠ pullRequestTitlePattern miss the part of '${scope}'
⚠ pullRequestTitlePattern miss the part of '${component}'
⚠ pullRequestTitlePattern miss the part of '${version}'
❯ Found pull request #67: 'chore: release main'
⚠ There are untagged, merged release PRs outstanding - aborting

That abort is a consequence, not the cause. Earlier in the same run, in the Building releases phase, is the real failure:

✔ Building release for path: .
⚠ PR component: undefined does not match configured component: nl2sql-engine

Root cause: getComponent() and getBranchComponent() disagree

release-please v17.3.0, src/strategies/base.ts:

asyncgetComponent(){if(!this.includeComponentInTag)return''; ... }// -> ""asyncgetBranchComponent(){returnthis.component|| ...;}// -> "nl2sql-engine"

getBranchComponent() ignores include-component-in-tag; getComponent() honours it. package-name: "nl2sql-engine" is what populated this.component.

Meanwhile, because separate-pull-requests is false, the Merge plugin names the grouped release branch itself:

headRefName: this.headBranchName??BranchName.ofTargetBranch(this.targetBranch).toString(),

giving release-please--branches--main — no component in it. On the way back, buildRelease compares branchName.component (undefined) against getBranchComponent() (nl2sql-engine), mismatches, and returns without building a release. No tag, ever.

This only bites with exactly one root package, grouping on, package-name set, and include-component-in-tag: false.

Verification

Driven against this repo and PR #67's real body through strategy.buildReleases() on release-please 17.3.0 — the exact version CI runs:

Config	Merged PR title	Result
current	chore: release main	NO RELEASE — PR component: undefined does not match configured component: nl2sql-engine (reproduces CI exactly)
current + group-pull-request-title-pattern	chore: release 0.1.0	NO RELEASE — same component mismatch
this PR (no package-name)	chore: release main	tag=v0.1.0 ✅
no package-name + title pattern	chore: release main	NO RELEASE — Bad pull request title

Row 2 is the important one: changing the title pattern does not fix this. Row 4 is why it must not be changed — see below.

The title-pattern warnings are noise

pullRequestTitlePattern miss the part of '${...}' fires unconditionally whenever a pattern omits a placeholder. The built-in grouped-PR default is chore: release ${branch} (src/manifest.ts:295), which omits all three, so these warnings appear on healthy runs too.

A title without ${version} is not fatal. Release-please falls back to the PR body, whose <summary>0.1.0</summary> block carries the version — the documentation says it parses it "either via the pull request title or body format".

Do not strip autorelease: pending from #67

#67's label must be left alone, or 0.1.0 is stranded permanently.

With this fix, #67 tags v0.1.0 from its body, release-please swaps its label to autorelease: tagged, and the abort clears on its own. publish_pypi.yaml then fires on v0.1.0 (tags: ["v*"] — tag naming is unaffected, verified v0.1.0).

Stripping the label instead makes release-please forget #67 entirely. The manifest already reads 0.1.0, so the next release PR would bump 0.1.0 → 0.2.0 and 0.1.0 would never be published.

Why removing package-name is safe

It was inert apart from the bug. src/strategies/python.ts sets projectName = pyProject.name, so the __init__.py and changelog.json updaters read the root pyproject.toml — whose name is nl2sql-monorepo, not nl2sql-engine. The set of files release-please updates is unchanged, and getComponent() was already "".

Also in this PR

A troubleshooting section in docs/development/releasing.md recording both traps with their exact greppable symptoms: this component mismatch (including that the pullRequestTitlePattern warnings are not the cause — that misdiagnosis cost a cycle), and that the manifest holds the last released version and must be seeded below the first target.

No version, CHANGELOG.md, or .release-please-manifest.json was touched. Unit 231 passed, 1 skipped, 47 deselected and key-free integration 28 passed, both twice; mkdocs build --strict clean.

[nadeem4]

Release-please has refused to create the v0.1.0 tag across three cycles. It finds the correct merged release PR (#67) and then aborts:

✔ Merging 1 pull requests
⚠ pullRequestTitlePattern miss the part of '${scope}'
⚠ pullRequestTitlePattern miss the part of '${component}'
⚠ pullRequestTitlePattern miss the part of '${version}'
❯ Found pull request #67: 'chore: release main'
⚠ There are untagged, merged release PRs outstanding - aborting

That abort is a consequence, not the cause. Earlier in the same run, in the Building releases phase, is the real failure:

✔ Building release for path: .
⚠ PR component: undefined does not match configured component: nl2sql-engine

Root cause: getComponent() and getBranchComponent() disagree

release-please v17.3.0, src/strategies/base.ts:

asyncgetComponent(){if(!this.includeComponentInTag)return''; ... }// -> ""asyncgetBranchComponent(){returnthis.component|| ...;}// -> "nl2sql-engine"

getBranchComponent() ignores include-component-in-tag; getComponent() honours it. package-name: "nl2sql-engine" is what populated this.component.

Meanwhile, because separate-pull-requests is false, the Merge plugin names the grouped release branch itself:

headRefName: this.headBranchName??BranchName.ofTargetBranch(this.targetBranch).toString(),

giving release-please--branches--main — no component in it. On the way back, buildRelease compares branchName.component (undefined) against getBranchComponent() (nl2sql-engine), mismatches, and returns without building a release. No tag, ever.

This only bites with exactly one root package, grouping on, package-name set, and include-component-in-tag: false.

Verification

Driven against this repo and PR #67's real body through strategy.buildReleases() on release-please 17.3.0 — the exact version CI runs:

Config	Merged PR title	Result
current	chore: release main	NO RELEASE — PR component: undefined does not match configured component: nl2sql-engine (reproduces CI exactly)
current + group-pull-request-title-pattern	chore: release 0.1.0	NO RELEASE — same component mismatch
this PR (no package-name)	chore: release main	tag=v0.1.0 ✅
no package-name + title pattern	chore: release main	NO RELEASE — Bad pull request title

Row 2 is the important one: changing the title pattern does not fix this. Row 4 is why it must not be changed — see below.

The title-pattern warnings are noise

pullRequestTitlePattern miss the part of '${...}' fires unconditionally whenever a pattern omits a placeholder. The built-in grouped-PR default is chore: release ${branch} (src/manifest.ts:295), which omits all three, so these warnings appear on healthy runs too.

A title without ${version} is not fatal. Release-please falls back to the PR body, whose <summary>0.1.0</summary> block carries the version — the documentation says it parses it "either via the pull request title or body format".

Do not strip autorelease: pending from #67

#67's label must be left alone, or 0.1.0 is stranded permanently.

With this fix, #67 tags v0.1.0 from its body, release-please swaps its label to autorelease: tagged, and the abort clears on its own. publish_pypi.yaml then fires on v0.1.0 (tags: ["v*"] — tag naming is unaffected, verified v0.1.0).

Stripping the label instead makes release-please forget #67 entirely. The manifest already reads 0.1.0, so the next release PR would bump 0.1.0 → 0.2.0 and 0.1.0 would never be published.

Why removing package-name is safe

It was inert apart from the bug. src/strategies/python.ts sets projectName = pyProject.name, so the __init__.py and changelog.json updaters read the root pyproject.toml — whose name is nl2sql-monorepo, not nl2sql-engine. The set of files release-please updates is unchanged, and getComponent() was already "".

Also in this PR

A troubleshooting section in docs/development/releasing.md recording both traps with their exact greppable symptoms: this component mismatch (including that the pullRequestTitlePattern warnings are not the cause — that misdiagnosis cost a cycle), and that the manifest holds the last released version and must be seeded below the first target.

No version, CHANGELOG.md, or .release-please-manifest.json was touched. Unit 231 passed, 1 skipped, 47 deselected and key-free integration 28 passed, both twice; mkdocs build --strict clean.