fix(ci): stop publishing to PyPI through a reusable workflow (#102)

* fix(ci): stop publishing to PyPI through a reusable workflow

PyPI does not accept a reusable workflow as a trusted publisher --
pypi/warehouse#11096, unresolved. Both publish jobs here called
reqstool/.github's python-publish-to-pypi.yml via workflow_call, so
every real publish attempt failed at the OIDC exchange with
invalid-publisher regardless of what the trusted publisher config
named -- confirmed today, and it explains why publish-dev-to-testpypi.yml
has been failing on every push to main since the 2026-08-16 migration.

Switches both jobs to reqstool/.github's new actions/publish-to-pypi
composite action, called directly from a job defined in this workflow.
A composite action doesn't have the same problem: the OIDC claim is
about which workflow file the job runs in, not what its steps reference.

The two-index environment derivation (testpypi -> test, pypi -> stable)
that the reusable workflow computed internally now has to be explicit
per job -- a composite action can't set the caller's environment:.

Needs reqstool/.github#92 merged first.

Signed-off-by: Jimisola Laursen <jimisola@jimisola.com>

* fix(ci): drop Test PyPI entirely rather than fix its trusted publisher

PyPI accepts a pre-release version identifier (0.3.0rc1) on the real
index directly, and pip ignores it without --pre -- there was never a
need to route a release candidate to a separate staging index to hold
it safely. Test PyPI existed here only as that safety net.

publish-to-pypi now runs unconditionally instead of skipping for a
release candidate, which also makes this consistent with what npm and
Maven Central already do. publish-dev-to-testpypi.yml is deleted --
it's been failing on every push to main since the 2026-08-16 migration
anyway (see reqstool/.github#92), and there's nowhere left for it to
publish to.

Needs reqstool/.github#92 merged first.

Signed-off-by: Jimisola Laursen <jimisola@jimisola.com>

* fix(ci): pin the publish-to-pypi action reference to a commit

CodeQL flagged actions/unpinned-tag: @main is a mutable ref, so a
compromised or force-pushed reqstool/.github main would execute
through this reference with no review. Pinned to the commit main
pointed at when this action was added, matching the org's existing
`@<sha> # main YYYY-MM-DD` convention for third-party/internal action
references elsewhere in this repo.

Signed-off-by: Jimisola Laursen <jimisola@jimisola.com>

---------

Signed-off-by: Jimisola Laursen <jimisola@jimisola.com>

Author: jimisola

.github/workflows/publish-dev-to-testpypi.yml

@@ -95,43 +95,35 @@ jobs:
       version: ${{ needs.prepare.outputs.version }}
       artifact: dist-tagged
 
-  publish-to-testpypi:
-    needs: [prepare, assets]
-    uses: reqstool/.github/.github/workflows/python-publish-to-pypi.yml@main
-    permissions:
-      id-token: write
-    with:
-      target: testpypi
-      artifact: dist-tagged
-
   # PyPI is the only step here that cannot be undone: a version can be yanked but
-  # never replaced. A release candidate stops at Test PyPI -- pip needs --pre to
-  # see a prerelease anyway.
+  # never replaced. Publishes release candidates too, with their pre-release
+  # identifier -- pip ignores them without --pre, so there is nothing unsafe
+  # about it landing on the real index; there is no separate staging index to
+  # route them to instead. Matches npm and Maven Central's existing behavior.
   publish-to-pypi:
-    needs: [prepare, publish-to-testpypi]
-    if: ${{ needs.prepare.outputs.prerelease != 'true' }}
-    uses: reqstool/.github/.github/workflows/python-publish-to-pypi.yml@main
+    needs: [prepare, assets]
+    runs-on: ubuntu-latest
+    environment:
+      name: stable
+      url: https://pypi.org
     permissions:
       id-token: write
-    with:
-      target: pypi
-      artifact: dist-tagged
+    steps:
+      - uses: reqstool/.github/.github/actions/publish-to-pypi@b10b898cd5a1d552a578dbe4f170f84fb8f98b6c # main 2026-08-23
+        with:
+          artifact: dist-tagged
 
   # Last, deliberately. Everything above can fail, and until this runs nothing
   # resolving "the latest release" can see what was built -- the release is still
   # a prerelease. Promotion itself is one API call against a release that already
   # has its artifacts.
   #
-  # The guard is `no job failed`, not the default `every job succeeded`: a release
-  # candidate deliberately skips the publish jobs that a real release runs, and a
-  # skipped dependency would otherwise cascade and skip this too -- leaving the
-  # candidate unpromoted, which is right, and every *real* release unpromoted the
-  # moment any optional job is skipped, which is not.
-  #
-  # `!inputs.dry-run` has to be spelled out for the same reason: on a dry run
-  # every job above is skipped, and "nothing failed" would otherwise be true.
+  # The guard is `no job failed`, not the default `every job succeeded`: on a dry
+  # run every job above is skipped, which would make plain success() false too --
+  # `!inputs.dry-run` is what actually gates this job then, and `no job failed`
+  # is what confirms nothing above it errored on a real run.
   promote:
-    needs: [prepare, assets, publish-to-testpypi, publish-to-pypi]
+    needs: [prepare, assets, publish-to-pypi]
     if: ${{ !inputs.dry-run && !cancelled() && !contains(needs.*.result, 'failure') && !contains(needs.*.result, 'cancelled') }}
     uses: reqstool/.github/.github/workflows/common-release-promote.yml@main
     permissions: