ci: publish from release-please outputs and allow manual dispatch

[nadeem4]

The defect

v0.1.0 is tagged and its GitHub Release is published, PR #67 flipped to
autorelease: tagged — but publish_pypi.yaml never ran, so nothing was
uploaded to PyPI, GHCR or the versioned docs.

GitHub does not trigger workflows from events created with the default
GITHUB_TOKEN. It is a deliberate recursion guard with no opt-out short of
pushing the tag with a PAT. release-please-action tags with that token, and
publish_pypi.yaml triggered only on push: tags: ["v*"], so it could never
fire from a release-please tag.

Evidence:

• v0.1.0 → daed7c09e64fc337078daf6b9459b5ce0f9a8021, and the GitHub Release
  is authored by github-actions[bot].
• gh run list shows Publish Release with no run at all — not a failed
  one, not a skipped one. It was never started.

Fix 1 — make this release publishable (workflow_dispatch)

publish_pypi.yaml gains workflow_dispatch with a required tag input, so
the existing v0.1.0 tag can be published by hand without re-tagging anything.

On a dispatched run github.ref is the branch and github.ref_name is main,
not v0.1.0, so every reference to the tag had to be audited. All four are now
${{ inputs.tag || github.ref_name }} — the input on a dispatched or called run,
the pushed tag otherwise:

• build checkout ref: (previously defaulted to the branch on dispatch)
• ghcr checkout ref:and the ghcr.io/nadeem4/nl2sql-api:<tag> image tag
• docs checkout ref: and mike deploy --push --update-aliases "$TAG" latest
  (was $GITHUB_REF_NAME, which would have deployed a docs version literally
  named main and moved latest onto it)

A dispatch therefore builds, publishes and documents the tagged commit, not
whatever main happens to be — which matters here, since main has already
moved past the tag (#68).

Fix 2 — stop depending on the cross-workflow trigger

release_please.yml now gives the action step an id, re-exports its outputs on
the job, and calls the publish directly:

release-please:
outputs:
releases_created: ${{ steps.release.outputs.releases_created }}tag_name: ${{ steps.release.outputs.tag_name }}publish:
needs: release-pleaseif: ${{ needs.release-please.outputs.releases_created == 'true' }}uses: ./.github/workflows/publish_pypi.yamlwith:
tag: ${{ needs.release-please.outputs.tag_name }}permissions:
contents: writepackages: writeid-token: write

Output names confirmed from the action's own README at v4, not assumed:
releases_created — "true if any release was created, false otherwise"; and
under Root component outputs (which apply because this repo's manifest has a
single package at path .), tag_name — "Directly related to Create a
release API".

workflow_call, not a duplicate pipeline. The build → smoke gate → three
PyPI legs → GHCR → docs chain stays in publish_pypi.yaml unchanged, which is
also the workflow filename registered with PyPI's trusted publishers — the
pypi job's OIDC claim still names it, so no publisher entry changes. The
alternative (moving publish jobs into release_please.yml) would have renamed
the workflow PyPI trusts and broken all three registrations.

id-token: write reaches the pypi legs fine: a called workflow's jobs can
never hold more than the calling job grants, so the caller declares the
ceiling and each inner job keeps its own narrower permissions block.

No PAT and no new secret. Trusted publishing was chosen to avoid stored
credentials; working around the trigger rule with a token would have defeated
that. The push: tags: ["v*"] trigger is kept as well — it costs nothing and
still covers a tag a human pushes by hand.

Unchanged

• Job order and the smoke gate: build (build 3 dists → smoke-install →
  import nl2sql → nl2sql --help) still needs-precedes pypi, and ghcr
  and docs both needs: pypi. If the wheels do not install and import,
  nothing publishes.
• The three environment names — pypi-nl2sql-engine, pypi-nl2sql-api,
  pypi-nl2sql-adapter-sdk — are the contract with PyPI's pending publishers
  and are byte-identical.
• No version, CHANGELOG.md or .release-please-manifest.json change.

Docs

docs/development/releasing.md gains two greppable subsections — Why the
publish is chained to release-please, not to the tag and Publishing a release
manually (gh workflow run publish_pypi.yaml -f tag=v0.1.0). mkdocs build --strict is clean.

Next step after merge

v0.1.0 is already tagged, so this change cannot retroactively trigger it.
The first publish will be a manual dispatch against the existing tag; every
release after this one publishes automatically off release-please's outputs.

[nadeem4]

The defect

v0.1.0 is tagged and its GitHub Release is published, PR #67 flipped to
autorelease: tagged — but publish_pypi.yaml never ran, so nothing was
uploaded to PyPI, GHCR or the versioned docs.

GitHub does not trigger workflows from events created with the default
GITHUB_TOKEN. It is a deliberate recursion guard with no opt-out short of
pushing the tag with a PAT. release-please-action tags with that token, and
publish_pypi.yaml triggered only on push: tags: ["v*"], so it could never
fire from a release-please tag.

Evidence:

• v0.1.0 → daed7c09e64fc337078daf6b9459b5ce0f9a8021, and the GitHub Release
  is authored by github-actions[bot].
• gh run list shows Publish Release with no run at all — not a failed
  one, not a skipped one. It was never started.

Fix 1 — make this release publishable (workflow_dispatch)

publish_pypi.yaml gains workflow_dispatch with a required tag input, so
the existing v0.1.0 tag can be published by hand without re-tagging anything.

On a dispatched run github.ref is the branch and github.ref_name is main,
not v0.1.0, so every reference to the tag had to be audited. All four are now
${{ inputs.tag || github.ref_name }} — the input on a dispatched or called run,
the pushed tag otherwise:

• build checkout ref: (previously defaulted to the branch on dispatch)
• ghcr checkout ref:and the ghcr.io/nadeem4/nl2sql-api:<tag> image tag
• docs checkout ref: and mike deploy --push --update-aliases "$TAG" latest
  (was $GITHUB_REF_NAME, which would have deployed a docs version literally
  named main and moved latest onto it)

A dispatch therefore builds, publishes and documents the tagged commit, not
whatever main happens to be — which matters here, since main has already
moved past the tag (#68).

Fix 2 — stop depending on the cross-workflow trigger

release_please.yml now gives the action step an id, re-exports its outputs on
the job, and calls the publish directly:

release-please:
outputs:
releases_created: ${{ steps.release.outputs.releases_created }}tag_name: ${{ steps.release.outputs.tag_name }}publish:
needs: release-pleaseif: ${{ needs.release-please.outputs.releases_created == 'true' }}uses: ./.github/workflows/publish_pypi.yamlwith:
tag: ${{ needs.release-please.outputs.tag_name }}permissions:
contents: writepackages: writeid-token: write

Output names confirmed from the action's own README at v4, not assumed:
releases_created — "true if any release was created, false otherwise"; and
under Root component outputs (which apply because this repo's manifest has a
single package at path .), tag_name — "Directly related to Create a
release API".

workflow_call, not a duplicate pipeline. The build → smoke gate → three
PyPI legs → GHCR → docs chain stays in publish_pypi.yaml unchanged, which is
also the workflow filename registered with PyPI's trusted publishers — the
pypi job's OIDC claim still names it, so no publisher entry changes. The
alternative (moving publish jobs into release_please.yml) would have renamed
the workflow PyPI trusts and broken all three registrations.

id-token: write reaches the pypi legs fine: a called workflow's jobs can
never hold more than the calling job grants, so the caller declares the
ceiling and each inner job keeps its own narrower permissions block.

No PAT and no new secret. Trusted publishing was chosen to avoid stored
credentials; working around the trigger rule with a token would have defeated
that. The push: tags: ["v*"] trigger is kept as well — it costs nothing and
still covers a tag a human pushes by hand.

Unchanged

• Job order and the smoke gate: build (build 3 dists → smoke-install →
  import nl2sql → nl2sql --help) still needs-precedes pypi, and ghcr
  and docs both needs: pypi. If the wheels do not install and import,
  nothing publishes.
• The three environment names — pypi-nl2sql-engine, pypi-nl2sql-api,
  pypi-nl2sql-adapter-sdk — are the contract with PyPI's pending publishers
  and are byte-identical.
• No version, CHANGELOG.md or .release-please-manifest.json change.

Docs

docs/development/releasing.md gains two greppable subsections — Why the
publish is chained to release-please, not to the tag and Publishing a release
manually (gh workflow run publish_pypi.yaml -f tag=v0.1.0). mkdocs build --strict is clean.

Next step after merge

v0.1.0 is already tagged, so this change cannot retroactively trigger it.
The first publish will be a manual dispatch against the existing tag; every
release after this one publishes automatically off release-please's outputs.

[nadeem4]

The defect

v0.1.0 is tagged and its GitHub Release is published, PR #67 flipped to
autorelease: tagged — but publish_pypi.yaml never ran, so nothing was
uploaded to PyPI, GHCR or the versioned docs.

GitHub does not trigger workflows from events created with the default
GITHUB_TOKEN. It is a deliberate recursion guard with no opt-out short of
pushing the tag with a PAT. release-please-action tags with that token, and
publish_pypi.yaml triggered only on push: tags: ["v*"], so it could never
fire from a release-please tag.

Evidence:

• v0.1.0 → daed7c09e64fc337078daf6b9459b5ce0f9a8021, and the GitHub Release
  is authored by github-actions[bot].
• gh run list shows Publish Release with no run at all — not a failed
  one, not a skipped one. It was never started.

Fix 1 — make this release publishable (workflow_dispatch)

publish_pypi.yaml gains workflow_dispatch with a required tag input, so
the existing v0.1.0 tag can be published by hand without re-tagging anything.

On a dispatched run github.ref is the branch and github.ref_name is main,
not v0.1.0, so every reference to the tag had to be audited. All four are now
${{ inputs.tag || github.ref_name }} — the input on a dispatched or called run,
the pushed tag otherwise:

• build checkout ref: (previously defaulted to the branch on dispatch)
• ghcr checkout ref:and the ghcr.io/nadeem4/nl2sql-api:<tag> image tag
• docs checkout ref: and mike deploy --push --update-aliases "$TAG" latest
  (was $GITHUB_REF_NAME, which would have deployed a docs version literally
  named main and moved latest onto it)

A dispatch therefore builds, publishes and documents the tagged commit, not
whatever main happens to be — which matters here, since main has already
moved past the tag (#68).

Fix 2 — stop depending on the cross-workflow trigger

release_please.yml now gives the action step an id, re-exports its outputs on
the job, and calls the publish directly:

release-please:
outputs:
releases_created: ${{ steps.release.outputs.releases_created }}tag_name: ${{ steps.release.outputs.tag_name }}publish:
needs: release-pleaseif: ${{ needs.release-please.outputs.releases_created == 'true' }}uses: ./.github/workflows/publish_pypi.yamlwith:
tag: ${{ needs.release-please.outputs.tag_name }}permissions:
contents: writepackages: writeid-token: write

Output names confirmed from the action's own README at v4, not assumed:
releases_created — "true if any release was created, false otherwise"; and
under Root component outputs (which apply because this repo's manifest has a
single package at path .), tag_name — "Directly related to Create a
release API".

workflow_call, not a duplicate pipeline. The build → smoke gate → three
PyPI legs → GHCR → docs chain stays in publish_pypi.yaml unchanged, which is
also the workflow filename registered with PyPI's trusted publishers — the
pypi job's OIDC claim still names it, so no publisher entry changes. The
alternative (moving publish jobs into release_please.yml) would have renamed
the workflow PyPI trusts and broken all three registrations.

id-token: write reaches the pypi legs fine: a called workflow's jobs can
never hold more than the calling job grants, so the caller declares the
ceiling and each inner job keeps its own narrower permissions block.

No PAT and no new secret. Trusted publishing was chosen to avoid stored
credentials; working around the trigger rule with a token would have defeated
that. The push: tags: ["v*"] trigger is kept as well — it costs nothing and
still covers a tag a human pushes by hand.

Unchanged

• Job order and the smoke gate: build (build 3 dists → smoke-install →
  import nl2sql → nl2sql --help) still needs-precedes pypi, and ghcr
  and docs both needs: pypi. If the wheels do not install and import,
  nothing publishes.
• The three environment names — pypi-nl2sql-engine, pypi-nl2sql-api,
  pypi-nl2sql-adapter-sdk — are the contract with PyPI's pending publishers
  and are byte-identical.
• No version, CHANGELOG.md or .release-please-manifest.json change.

Docs

docs/development/releasing.md gains two greppable subsections — Why the
publish is chained to release-please, not to the tag and Publishing a release
manually (gh workflow run publish_pypi.yaml -f tag=v0.1.0). mkdocs build --strict is clean.

Next step after merge

v0.1.0 is already tagged, so this change cannot retroactively trigger it.
The first publish will be a manual dispatch against the existing tag; every
release after this one publishes automatically off release-please's outputs.

[nadeem4]

The defect

v0.1.0 is tagged and its GitHub Release is published, PR #67 flipped to
autorelease: tagged — but publish_pypi.yaml never ran, so nothing was
uploaded to PyPI, GHCR or the versioned docs.

GitHub does not trigger workflows from events created with the default
GITHUB_TOKEN. It is a deliberate recursion guard with no opt-out short of
pushing the tag with a PAT. release-please-action tags with that token, and
publish_pypi.yaml triggered only on push: tags: ["v*"], so it could never
fire from a release-please tag.

Evidence:

• v0.1.0 → daed7c09e64fc337078daf6b9459b5ce0f9a8021, and the GitHub Release
  is authored by github-actions[bot].
• gh run list shows Publish Release with no run at all — not a failed
  one, not a skipped one. It was never started.

Fix 1 — make this release publishable (workflow_dispatch)

publish_pypi.yaml gains workflow_dispatch with a required tag input, so
the existing v0.1.0 tag can be published by hand without re-tagging anything.

On a dispatched run github.ref is the branch and github.ref_name is main,
not v0.1.0, so every reference to the tag had to be audited. All four are now
${{ inputs.tag || github.ref_name }} — the input on a dispatched or called run,
the pushed tag otherwise:

• build checkout ref: (previously defaulted to the branch on dispatch)
• ghcr checkout ref:and the ghcr.io/nadeem4/nl2sql-api:<tag> image tag
• docs checkout ref: and mike deploy --push --update-aliases "$TAG" latest
  (was $GITHUB_REF_NAME, which would have deployed a docs version literally
  named main and moved latest onto it)

A dispatch therefore builds, publishes and documents the tagged commit, not
whatever main happens to be — which matters here, since main has already
moved past the tag (#68).

Fix 2 — stop depending on the cross-workflow trigger

release_please.yml now gives the action step an id, re-exports its outputs on
the job, and calls the publish directly:

release-please:
outputs:
releases_created: ${{ steps.release.outputs.releases_created }}tag_name: ${{ steps.release.outputs.tag_name }}publish:
needs: release-pleaseif: ${{ needs.release-please.outputs.releases_created == 'true' }}uses: ./.github/workflows/publish_pypi.yamlwith:
tag: ${{ needs.release-please.outputs.tag_name }}permissions:
contents: writepackages: writeid-token: write

Output names confirmed from the action's own README at v4, not assumed:
releases_created — "true if any release was created, false otherwise"; and
under Root component outputs (which apply because this repo's manifest has a
single package at path .), tag_name — "Directly related to Create a
release API".

workflow_call, not a duplicate pipeline. The build → smoke gate → three
PyPI legs → GHCR → docs chain stays in publish_pypi.yaml unchanged, which is
also the workflow filename registered with PyPI's trusted publishers — the
pypi job's OIDC claim still names it, so no publisher entry changes. The
alternative (moving publish jobs into release_please.yml) would have renamed
the workflow PyPI trusts and broken all three registrations.

id-token: write reaches the pypi legs fine: a called workflow's jobs can
never hold more than the calling job grants, so the caller declares the
ceiling and each inner job keeps its own narrower permissions block.

No PAT and no new secret. Trusted publishing was chosen to avoid stored
credentials; working around the trigger rule with a token would have defeated
that. The push: tags: ["v*"] trigger is kept as well — it costs nothing and
still covers a tag a human pushes by hand.

Unchanged

• Job order and the smoke gate: build (build 3 dists → smoke-install →
  import nl2sql → nl2sql --help) still needs-precedes pypi, and ghcr
  and docs both needs: pypi. If the wheels do not install and import,
  nothing publishes.
• The three environment names — pypi-nl2sql-engine, pypi-nl2sql-api,
  pypi-nl2sql-adapter-sdk — are the contract with PyPI's pending publishers
  and are byte-identical.
• No version, CHANGELOG.md or .release-please-manifest.json change.

Docs

docs/development/releasing.md gains two greppable subsections — Why the
publish is chained to release-please, not to the tag and Publishing a release
manually (gh workflow run publish_pypi.yaml -f tag=v0.1.0). mkdocs build --strict is clean.

Next step after merge

v0.1.0 is already tagged, so this change cannot retroactively trigger it.
The first publish will be a manual dispatch against the existing tag; every
release after this one publishes automatically off release-please's outputs.

[nadeem4]

The defect

v0.1.0 is tagged and its GitHub Release is published, PR #67 flipped to
autorelease: tagged — but publish_pypi.yaml never ran, so nothing was
uploaded to PyPI, GHCR or the versioned docs.

GitHub does not trigger workflows from events created with the default
GITHUB_TOKEN. It is a deliberate recursion guard with no opt-out short of
pushing the tag with a PAT. release-please-action tags with that token, and
publish_pypi.yaml triggered only on push: tags: ["v*"], so it could never
fire from a release-please tag.

Evidence:

• v0.1.0 → daed7c09e64fc337078daf6b9459b5ce0f9a8021, and the GitHub Release
  is authored by github-actions[bot].
• gh run list shows Publish Release with no run at all — not a failed
  one, not a skipped one. It was never started.

Fix 1 — make this release publishable (workflow_dispatch)

publish_pypi.yaml gains workflow_dispatch with a required tag input, so
the existing v0.1.0 tag can be published by hand without re-tagging anything.

On a dispatched run github.ref is the branch and github.ref_name is main,
not v0.1.0, so every reference to the tag had to be audited. All four are now
${{ inputs.tag || github.ref_name }} — the input on a dispatched or called run,
the pushed tag otherwise:

• build checkout ref: (previously defaulted to the branch on dispatch)
• ghcr checkout ref:and the ghcr.io/nadeem4/nl2sql-api:<tag> image tag
• docs checkout ref: and mike deploy --push --update-aliases "$TAG" latest
  (was $GITHUB_REF_NAME, which would have deployed a docs version literally
  named main and moved latest onto it)

A dispatch therefore builds, publishes and documents the tagged commit, not
whatever main happens to be — which matters here, since main has already
moved past the tag (#68).

Fix 2 — stop depending on the cross-workflow trigger

release_please.yml now gives the action step an id, re-exports its outputs on
the job, and calls the publish directly:

release-please:
outputs:
releases_created: ${{ steps.release.outputs.releases_created }}tag_name: ${{ steps.release.outputs.tag_name }}publish:
needs: release-pleaseif: ${{ needs.release-please.outputs.releases_created == 'true' }}uses: ./.github/workflows/publish_pypi.yamlwith:
tag: ${{ needs.release-please.outputs.tag_name }}permissions:
contents: writepackages: writeid-token: write

Output names confirmed from the action's own README at v4, not assumed:
releases_created — "true if any release was created, false otherwise"; and
under Root component outputs (which apply because this repo's manifest has a
single package at path .), tag_name — "Directly related to Create a
release API".

workflow_call, not a duplicate pipeline. The build → smoke gate → three
PyPI legs → GHCR → docs chain stays in publish_pypi.yaml unchanged, which is
also the workflow filename registered with PyPI's trusted publishers — the
pypi job's OIDC claim still names it, so no publisher entry changes. The
alternative (moving publish jobs into release_please.yml) would have renamed
the workflow PyPI trusts and broken all three registrations.

id-token: write reaches the pypi legs fine: a called workflow's jobs can
never hold more than the calling job grants, so the caller declares the
ceiling and each inner job keeps its own narrower permissions block.

No PAT and no new secret. Trusted publishing was chosen to avoid stored
credentials; working around the trigger rule with a token would have defeated
that. The push: tags: ["v*"] trigger is kept as well — it costs nothing and
still covers a tag a human pushes by hand.

Unchanged

• Job order and the smoke gate: build (build 3 dists → smoke-install →
  import nl2sql → nl2sql --help) still needs-precedes pypi, and ghcr
  and docs both needs: pypi. If the wheels do not install and import,
  nothing publishes.
• The three environment names — pypi-nl2sql-engine, pypi-nl2sql-api,
  pypi-nl2sql-adapter-sdk — are the contract with PyPI's pending publishers
  and are byte-identical.
• No version, CHANGELOG.md or .release-please-manifest.json change.

Docs

docs/development/releasing.md gains two greppable subsections — Why the
publish is chained to release-please, not to the tag and Publishing a release
manually (gh workflow run publish_pypi.yaml -f tag=v0.1.0). mkdocs build --strict is clean.

Next step after merge

v0.1.0 is already tagged, so this change cannot retroactively trigger it.
The first publish will be a manual dispatch against the existing tag; every
release after this one publishes automatically off release-please's outputs.

[nadeem4]

The defect

v0.1.0 is tagged and its GitHub Release is published, PR #67 flipped to
autorelease: tagged — but publish_pypi.yaml never ran, so nothing was
uploaded to PyPI, GHCR or the versioned docs.

GitHub does not trigger workflows from events created with the default
GITHUB_TOKEN. It is a deliberate recursion guard with no opt-out short of
pushing the tag with a PAT. release-please-action tags with that token, and
publish_pypi.yaml triggered only on push: tags: ["v*"], so it could never
fire from a release-please tag.

Evidence:

• v0.1.0 → daed7c09e64fc337078daf6b9459b5ce0f9a8021, and the GitHub Release
  is authored by github-actions[bot].
• gh run list shows Publish Release with no run at all — not a failed
  one, not a skipped one. It was never started.

Fix 1 — make this release publishable (workflow_dispatch)

publish_pypi.yaml gains workflow_dispatch with a required tag input, so
the existing v0.1.0 tag can be published by hand without re-tagging anything.

On a dispatched run github.ref is the branch and github.ref_name is main,
not v0.1.0, so every reference to the tag had to be audited. All four are now
${{ inputs.tag || github.ref_name }} — the input on a dispatched or called run,
the pushed tag otherwise:

• build checkout ref: (previously defaulted to the branch on dispatch)
• ghcr checkout ref:and the ghcr.io/nadeem4/nl2sql-api:<tag> image tag
• docs checkout ref: and mike deploy --push --update-aliases "$TAG" latest
  (was $GITHUB_REF_NAME, which would have deployed a docs version literally
  named main and moved latest onto it)

A dispatch therefore builds, publishes and documents the tagged commit, not
whatever main happens to be — which matters here, since main has already
moved past the tag (#68).

Fix 2 — stop depending on the cross-workflow trigger

release_please.yml now gives the action step an id, re-exports its outputs on
the job, and calls the publish directly:

release-please:
outputs:
releases_created: ${{ steps.release.outputs.releases_created }}tag_name: ${{ steps.release.outputs.tag_name }}publish:
needs: release-pleaseif: ${{ needs.release-please.outputs.releases_created == 'true' }}uses: ./.github/workflows/publish_pypi.yamlwith:
tag: ${{ needs.release-please.outputs.tag_name }}permissions:
contents: writepackages: writeid-token: write

Output names confirmed from the action's own README at v4, not assumed:
releases_created — "true if any release was created, false otherwise"; and
under Root component outputs (which apply because this repo's manifest has a
single package at path .), tag_name — "Directly related to Create a
release API".

workflow_call, not a duplicate pipeline. The build → smoke gate → three
PyPI legs → GHCR → docs chain stays in publish_pypi.yaml unchanged, which is
also the workflow filename registered with PyPI's trusted publishers — the
pypi job's OIDC claim still names it, so no publisher entry changes. The
alternative (moving publish jobs into release_please.yml) would have renamed
the workflow PyPI trusts and broken all three registrations.

id-token: write reaches the pypi legs fine: a called workflow's jobs can
never hold more than the calling job grants, so the caller declares the
ceiling and each inner job keeps its own narrower permissions block.

No PAT and no new secret. Trusted publishing was chosen to avoid stored
credentials; working around the trigger rule with a token would have defeated
that. The push: tags: ["v*"] trigger is kept as well — it costs nothing and
still covers a tag a human pushes by hand.

Unchanged

• Job order and the smoke gate: build (build 3 dists → smoke-install →
  import nl2sql → nl2sql --help) still needs-precedes pypi, and ghcr
  and docs both needs: pypi. If the wheels do not install and import,
  nothing publishes.
• The three environment names — pypi-nl2sql-engine, pypi-nl2sql-api,
  pypi-nl2sql-adapter-sdk — are the contract with PyPI's pending publishers
  and are byte-identical.
• No version, CHANGELOG.md or .release-please-manifest.json change.

Docs

docs/development/releasing.md gains two greppable subsections — Why the
publish is chained to release-please, not to the tag and Publishing a release
manually (gh workflow run publish_pypi.yaml -f tag=v0.1.0). mkdocs build --strict is clean.

Next step after merge

v0.1.0 is already tagged, so this change cannot retroactively trigger it.
The first publish will be a manual dispatch against the existing tag; every
release after this one publishes automatically off release-please's outputs.

[nadeem4]

The defect

v0.1.0 is tagged and its GitHub Release is published, PR #67 flipped to
autorelease: tagged — but publish_pypi.yaml never ran, so nothing was
uploaded to PyPI, GHCR or the versioned docs.

GitHub does not trigger workflows from events created with the default
GITHUB_TOKEN. It is a deliberate recursion guard with no opt-out short of
pushing the tag with a PAT. release-please-action tags with that token, and
publish_pypi.yaml triggered only on push: tags: ["v*"], so it could never
fire from a release-please tag.

Evidence:

• v0.1.0 → daed7c09e64fc337078daf6b9459b5ce0f9a8021, and the GitHub Release
  is authored by github-actions[bot].
• gh run list shows Publish Release with no run at all — not a failed
  one, not a skipped one. It was never started.

Fix 1 — make this release publishable (workflow_dispatch)

publish_pypi.yaml gains workflow_dispatch with a required tag input, so
the existing v0.1.0 tag can be published by hand without re-tagging anything.

On a dispatched run github.ref is the branch and github.ref_name is main,
not v0.1.0, so every reference to the tag had to be audited. All four are now
${{ inputs.tag || github.ref_name }} — the input on a dispatched or called run,
the pushed tag otherwise:

• build checkout ref: (previously defaulted to the branch on dispatch)
• ghcr checkout ref:and the ghcr.io/nadeem4/nl2sql-api:<tag> image tag
• docs checkout ref: and mike deploy --push --update-aliases "$TAG" latest
  (was $GITHUB_REF_NAME, which would have deployed a docs version literally
  named main and moved latest onto it)

A dispatch therefore builds, publishes and documents the tagged commit, not
whatever main happens to be — which matters here, since main has already
moved past the tag (#68).

Fix 2 — stop depending on the cross-workflow trigger

release_please.yml now gives the action step an id, re-exports its outputs on
the job, and calls the publish directly:

release-please:
outputs:
releases_created: ${{ steps.release.outputs.releases_created }}tag_name: ${{ steps.release.outputs.tag_name }}publish:
needs: release-pleaseif: ${{ needs.release-please.outputs.releases_created == 'true' }}uses: ./.github/workflows/publish_pypi.yamlwith:
tag: ${{ needs.release-please.outputs.tag_name }}permissions:
contents: writepackages: writeid-token: write

Output names confirmed from the action's own README at v4, not assumed:
releases_created — "true if any release was created, false otherwise"; and
under Root component outputs (which apply because this repo's manifest has a
single package at path .), tag_name — "Directly related to Create a
release API".

workflow_call, not a duplicate pipeline. The build → smoke gate → three
PyPI legs → GHCR → docs chain stays in publish_pypi.yaml unchanged, which is
also the workflow filename registered with PyPI's trusted publishers — the
pypi job's OIDC claim still names it, so no publisher entry changes. The
alternative (moving publish jobs into release_please.yml) would have renamed
the workflow PyPI trusts and broken all three registrations.

id-token: write reaches the pypi legs fine: a called workflow's jobs can
never hold more than the calling job grants, so the caller declares the
ceiling and each inner job keeps its own narrower permissions block.

No PAT and no new secret. Trusted publishing was chosen to avoid stored
credentials; working around the trigger rule with a token would have defeated
that. The push: tags: ["v*"] trigger is kept as well — it costs nothing and
still covers a tag a human pushes by hand.

Unchanged

• Job order and the smoke gate: build (build 3 dists → smoke-install →
  import nl2sql → nl2sql --help) still needs-precedes pypi, and ghcr
  and docs both needs: pypi. If the wheels do not install and import,
  nothing publishes.
• The three environment names — pypi-nl2sql-engine, pypi-nl2sql-api,
  pypi-nl2sql-adapter-sdk — are the contract with PyPI's pending publishers
  and are byte-identical.
• No version, CHANGELOG.md or .release-please-manifest.json change.

Docs

docs/development/releasing.md gains two greppable subsections — Why the
publish is chained to release-please, not to the tag and Publishing a release
manually (gh workflow run publish_pypi.yaml -f tag=v0.1.0). mkdocs build --strict is clean.

Next step after merge

v0.1.0 is already tagged, so this change cannot retroactively trigger it.
The first publish will be a manual dispatch against the existing tag; every
release after this one publishes automatically off release-please's outputs.

[nadeem4]

The defect

v0.1.0 is tagged and its GitHub Release is published, PR #67 flipped to
autorelease: tagged — but publish_pypi.yaml never ran, so nothing was
uploaded to PyPI, GHCR or the versioned docs.

GitHub does not trigger workflows from events created with the default
GITHUB_TOKEN. It is a deliberate recursion guard with no opt-out short of
pushing the tag with a PAT. release-please-action tags with that token, and
publish_pypi.yaml triggered only on push: tags: ["v*"], so it could never
fire from a release-please tag.

Evidence:

• v0.1.0 → daed7c09e64fc337078daf6b9459b5ce0f9a8021, and the GitHub Release
  is authored by github-actions[bot].
• gh run list shows Publish Release with no run at all — not a failed
  one, not a skipped one. It was never started.

Fix 1 — make this release publishable (workflow_dispatch)

publish_pypi.yaml gains workflow_dispatch with a required tag input, so
the existing v0.1.0 tag can be published by hand without re-tagging anything.

On a dispatched run github.ref is the branch and github.ref_name is main,
not v0.1.0, so every reference to the tag had to be audited. All four are now
${{ inputs.tag || github.ref_name }} — the input on a dispatched or called run,
the pushed tag otherwise:

• build checkout ref: (previously defaulted to the branch on dispatch)
• ghcr checkout ref:and the ghcr.io/nadeem4/nl2sql-api:<tag> image tag
• docs checkout ref: and mike deploy --push --update-aliases "$TAG" latest
  (was $GITHUB_REF_NAME, which would have deployed a docs version literally
  named main and moved latest onto it)

A dispatch therefore builds, publishes and documents the tagged commit, not
whatever main happens to be — which matters here, since main has already
moved past the tag (#68).

Fix 2 — stop depending on the cross-workflow trigger

release_please.yml now gives the action step an id, re-exports its outputs on
the job, and calls the publish directly:

release-please:
outputs:
releases_created: ${{ steps.release.outputs.releases_created }}tag_name: ${{ steps.release.outputs.tag_name }}publish:
needs: release-pleaseif: ${{ needs.release-please.outputs.releases_created == 'true' }}uses: ./.github/workflows/publish_pypi.yamlwith:
tag: ${{ needs.release-please.outputs.tag_name }}permissions:
contents: writepackages: writeid-token: write

Output names confirmed from the action's own README at v4, not assumed:
releases_created — "true if any release was created, false otherwise"; and
under Root component outputs (which apply because this repo's manifest has a
single package at path .), tag_name — "Directly related to Create a
release API".

workflow_call, not a duplicate pipeline. The build → smoke gate → three
PyPI legs → GHCR → docs chain stays in publish_pypi.yaml unchanged, which is
also the workflow filename registered with PyPI's trusted publishers — the
pypi job's OIDC claim still names it, so no publisher entry changes. The
alternative (moving publish jobs into release_please.yml) would have renamed
the workflow PyPI trusts and broken all three registrations.

id-token: write reaches the pypi legs fine: a called workflow's jobs can
never hold more than the calling job grants, so the caller declares the
ceiling and each inner job keeps its own narrower permissions block.

No PAT and no new secret. Trusted publishing was chosen to avoid stored
credentials; working around the trigger rule with a token would have defeated
that. The push: tags: ["v*"] trigger is kept as well — it costs nothing and
still covers a tag a human pushes by hand.

Unchanged

• Job order and the smoke gate: build (build 3 dists → smoke-install →
  import nl2sql → nl2sql --help) still needs-precedes pypi, and ghcr
  and docs both needs: pypi. If the wheels do not install and import,
  nothing publishes.
• The three environment names — pypi-nl2sql-engine, pypi-nl2sql-api,
  pypi-nl2sql-adapter-sdk — are the contract with PyPI's pending publishers
  and are byte-identical.
• No version, CHANGELOG.md or .release-please-manifest.json change.

Docs

docs/development/releasing.md gains two greppable subsections — Why the
publish is chained to release-please, not to the tag and Publishing a release
manually (gh workflow run publish_pypi.yaml -f tag=v0.1.0). mkdocs build --strict is clean.

Next step after merge

v0.1.0 is already tagged, so this change cannot retroactively trigger it.
The first publish will be a manual dispatch against the existing tag; every
release after this one publishes automatically off release-please's outputs.