Automate release process with workflow_dispatch

Add release.yml workflow that handles the full release:
prepare changelog, commit, tag, build, test, publish to PyPI,
create GitHub release, and start next development cycle.

Move publish jobs out of test.yml (CI only tests now).
Update RELEASING.rst with instructions to run the workflow.

Author: graingert

.github/workflows/release.yml

@@ -0,0 +1,62 @@
+name: Release
+
+on:
+  workflow_dispatch:
+    inputs:
+      version:
+        description: "Release version (e.g. 0.6)"
+        required: true
+
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    environment: release
+    permissions:
+      contents: write
+      id-token: write
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 0
+
+      - name: Configure git
+        run: |
+          git config user.name "github-actions[bot]"
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+
+      - name: Prepare changelog
+        run: python make_changelog.py "${{ github.event.inputs.version }}"
+
+      - name: Commit and tag
+        run: |
+          git commit -am "Prepare release ${{ github.event.inputs.version }}"
+          git tag "v${{ github.event.inputs.version }}"
+          git push origin "v${{ github.event.inputs.version }}"
+
+      - name: Build
+        uses: hynek/build-and-inspect-python-package@v2.14
+        with:
+          upload-name-suffix: -release
+
+      - name: Download Package
+        uses: actions/download-artifact@v8
+        with:
+          name: Packages-release
+          path: dist
+
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@v1.13.0
+        with:
+          attestations: true
+
+      - name: Create GitHub Release
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          gh release create "v${{ github.event.inputs.version }}" --generate-notes dist/*
+
+      - name: Start next development cycle
+        run: |
+          python make_changelog.py UNRELEASED
+          git commit -am "Start next development cycle"
+          git push origin main

.github/workflows/test.yml

@@ -79,45 +79,3 @@ jobs:
         shell: bash
         run: |
           tox run -e py --installpkg `find dist/*.tar.gz`
-
-  pypi-publish:
-    if: github.ref_type == 'tag'
-    needs: [changelog, package, test]
-    runs-on: ubuntu-latest
-    environment: release
-    permissions:
-      id-token: write
-
-    steps:
-      - name: Download Package
-        uses: actions/download-artifact@v8
-        with:
-          name: Packages
-          path: dist
-
-      - name: Publish to PyPI
-        uses: pypa/gh-action-pypi-publish@v1.13.0
-        with:
-          attestations: true
-
-  github-release:
-    if: github.ref_type == 'tag'
-    needs: [pypi-publish]
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v6
-
-      - name: Download Package
-        uses: actions/download-artifact@v8
-        with:
-          name: Packages
-          path: dist
-
-      - name: Create GitHub Release
-        env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        run: |
-          gh release create "${{ github.ref_name }}" --generate-notes dist/*

RELEASING.rst

@@ -8,59 +8,23 @@ Versions are derived automatically from git tags.
 .. _setuptools-scm: https://github.com/pypa/setuptools-scm
 
 
-Version
--------
-
-``main`` should always be green and a potential release candidate.
-``unittest2pytest`` follows semantic versioning, so given that the
-current version is ``X.Y.Z``, to find the next version number one
-needs to look at the ``CHANGELOG.rst`` file:
-
-- If there any new feature, then we must make a new **minor** release:
-  next release will be ``X.Y+1.0``.
-
-- Otherwise it is just a **bug fix** release: ``X.Y.Z+1``.
-
-
 Steps
 -----
 
-To publish a new release ``X.Y.Z``, the steps are as follows:
-
-#. Update ``CHANGELOG.rst``:
-
-   .. code-block:: console
-
-        python make_changelog.py X.Y.Z
-
-   This replaces the ``UNRELEASED`` section with a dated ``X.Y.Z``
-   section.  Review the result and add any missing entries before
-   committing.
-
-#. Commit and push:
-
-   .. code-block:: console
-
-        git commit -am "Prepare release X.Y.Z"
-        git push origin main
-
-#. Tag and push:
-
-   .. code-block:: console
-
-        git tag -s vX.Y.Z -m "unittest2pytest X.Y.Z"
-        git push origin vX.Y.Z
+Run the **Release** workflow from the Actions tab:
 
-   Pushing the tag triggers the CI workflow, which builds, tests,
-   publishes to PyPI, and creates a GitHub release.
+.. code-block:: console
 
-#. Start the next development cycle:
+     gh workflow run release.yml -R pytest-dev/unittest2pytest --field version=X.Y.Z
 
-   .. code-block:: console
+The workflow will:
 
-        python make_changelog.py UNRELEASED
-        git commit -am "Start next development cycle"
-        git push origin main
+#. Run ``make_changelog.py X.Y.Z`` to date the ``UNRELEASED`` section.
+#. Commit, tag ``vX.Y.Z``, and push.
+#. Run ``make_changelog.py UNRELEASED`` and push a follow-up commit.
+#. Build the package and run the full test matrix.
+#. Publish to PyPI (requires the ``release`` environment).
+#. Create a GitHub Release with the built artifacts.
 
 
 How versioning works