From 9ac9900c9559b2491fceb01d9dbc88e12811e898 Mon Sep 17 00:00:00 2001 From: Oscar V Date: Fri, 24 Jul 2026 12:08:48 -0700 Subject: [PATCH] Remove the release workflow that could never publish release.yml built the package on a v* tag push and then tried to upload it with trusted publishing and no environment. Its OIDC claims cannot match the PyPI publisher, which is configured for python-publish.yml with the pypi environment, so every run failed with invalid-publisher. The v1.3.5 run was the first, and the workflow did not exist as of v1.3.4. The failure also hid the release step: Create GitHub Release came after the upload in the same job, so a tag push produced no release at all. Dropping just the upload step would have been worse than leaving it. A release created by a workflow using GITHUB_TOKEN does not raise the release: published event, so python-publish.yml would not have started and the tag would have produced a release with nothing on PyPI. Every release so far, 1.3.2 through 1.3.5, was published by a user creating the GitHub release and python-publish.yml picking it up. That path works and is unchanged here, so the workflow is removed rather than repaired, which also matches mcp-semclone. CONTRIBUTING.md now documents the steps, including why the release has to be created by a user and how to verify the upload past the cached PyPI endpoint. --- .github/workflows/release.yml | 46 ----------------------------------- CONTRIBUTING.md | 26 ++++++++++++++++++++ 2 files changed, 26 insertions(+), 46 deletions(-) delete mode 100644 .github/workflows/release.yml diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml deleted file mode 100644 index c09c167..0000000 --- a/.github/workflows/release.yml +++ /dev/null @@ -1,46 +0,0 @@ -name: Release - -permissions: - contents: write - id-token: write - -on: - push: - tags: - - 'v*' - workflow_dispatch: - -jobs: - build-and-publish: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v7 - - - name: Set up Python - uses: actions/setup-python@v6 - with: - python-version: '3.13' - - - name: Install build dependencies - run: | - python -m pip install --upgrade pip - pip install build twine - - - name: Build package - run: python -m build - - - name: Check package - run: twine check dist/* - - - name: Publish to PyPI - if: startsWith(github.ref, 'refs/tags/') - uses: pypa/gh-action-pypi-publish@release/v1 - with: - skip-existing: true - - - name: Create GitHub Release - if: startsWith(github.ref, 'refs/tags/') - uses: softprops/action-gh-release@v3 - with: - files: dist/* - generate_release_notes: true diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0a43ae5..0c3ffc1 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -130,6 +130,32 @@ pytest --cov=src2purl pytest tests/test_specific.py ``` +## Releasing + +Publishing to PyPI runs from `.github/workflows/python-publish.yml`, which triggers when a +GitHub release is published and authenticates with PyPI trusted publishing through the `pypi` +environment. + +```bash +# 1. Bump the version in pyproject.toml and src2id/__init__.py, add a CHANGELOG entry, merge it +# 2. Tag the release commit +git tag -a vX.Y.Z -m "Release X.Y.Z" +git push origin vX.Y.Z + +# 3. Publish the release, which starts the PyPI upload +gh release create vX.Y.Z --title "X.Y.Z" --generate-notes +``` + +Release notes are generated by GitHub from the merged pull requests, so they do not need to be +written by hand. + +Step 3 has to be a real user action. A release created by a workflow using `GITHUB_TOKEN` does +not raise the `release: published` event, so the publish workflow would never start. + +Confirm the upload with the version-specific endpoint, `https://pypi.org/pypi/src2purl/X.Y.Z/json`. +The aggregate `https://pypi.org/pypi/src2purl/json` is cached and can lag a few minutes behind, +which looks like a failed upload when it is not. + ## Community You can chat with the community on: