Modernize test and deploy workflows

* Use dedicated workflow for publishing. * Update RELEASING and DEVELOPER docs. * Rename `CHANGES` to `CHANGELOG`, more commonly used in pytest-dev.
pytest-dev · Dec 10, 2024 · 9c370d9 · 9c370d9
1 parent dbdf7c2
commit 9c370d9
Show file tree

Hide file tree

Showing 8 changed files with 127 additions and 215 deletions.
diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
@@ -0,0 +1,48 @@
+name: deploy
+
+on:
+  workflow_dispatch:
+    inputs:
+      version:
+        description: 'Release version'
+        required: true
+        default: '1.2.3'
+
+jobs:
+
+  package:
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v4
+
+    - name: Build and Check Package
+      uses: hynek/[email protected]
+
+  deploy:
+    needs: package
+    runs-on: ubuntu-latest
+    permissions:
+      id-token: write  # For PyPI trusted publishers.
+      contents: write  # For tag.
+
+    steps:
+    - uses: actions/checkout@v4
+
+    - name: Download Package
+      uses: actions/download-artifact@v4
+      with:
+        name: Packages
+        path: dist
+
+    - name: Publish package to PyPI
+      uses: pypa/[email protected]
+      with:
+        attestations: true
+
+    - name: GitHub Release
+      env:
+        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      run: |
+        gh release create v${{ github.event.inputs.version }} --target=${{ github.ref_name }} --title v${{ github.event.inputs.version }}
+        gh pr merge ${{ github.ref_name }} --merge
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
@@ -1,12 +1,33 @@
 name: Test
 
-on: [push, pull_request, workflow_dispatch]
+on:
+  push:
+    branches:
+      - main
+      - "test-me-*"
+
+  pull_request:
+    branches:
+      - "*"
 
 env:
   FORCE_COLOR: 1
 
+# Cancel running jobs for the same workflow and branch.
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
 jobs:
+  package:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Build and Check Package
+        uses: hynek/[email protected]
+
   test:
+    needs: [package]
     runs-on: ${{ matrix.os }}
     strategy:
       fail-fast: false
@@ -18,31 +39,23 @@ jobs:
     steps:
       - uses: actions/checkout@v4
 
+      - name: Download Package
+        uses: actions/download-artifact@v4
+        with:
+          name: Packages
+          path: dist
+
       - name: Set up Python ${{ matrix.python-version }}
         uses: actions/setup-python@v5
         with:
           python-version: ${{ matrix.python-version }}
 
-      - name: Get pip cache dir
-        id: pip-cache
-        run: |
-          echo "dir=$(pip cache dir)" >> $GITHUB_OUTPUT
-
-      - name: Cache
-        uses: actions/cache@v4
-        with:
-          path: ${{ steps.pip-cache.outputs.dir }}
-          key:
-            ${{ matrix.os }}-${{ matrix.python-version }}-v1-${{ hashFiles('**/tox.ini') }}
-          restore-keys: |
-            ${{ matrix.os }}-${{ matrix.python-version }}-v1-
-
-      - name: Install dependencies
+      - name: Install tox
         run: |
           python -m pip install --upgrade pip
-          python -m pip install -e .
-          python -m pip install -r tests/requirements.txt
+          python -m pip install --upgrade tox
 
       - name: Test
+        shell: bash
         run: |
-          pytest -vv
+          tox run -e py --installpkg `find dist/*.tar.gz`
diff --git a/CHANGES.rst → CHANGELOG.rst b/CHANGES.rst → CHANGELOG.rst
diff --git a/DEVELOPER.rst b/DEVELOPER.rst
@@ -8,7 +8,7 @@ https://github.com/pytest-dev/unittest2pytest/actions.
 Prior to pushing a pull request to GitHub, please test locally::
 
   pip install tox pytest
-  tox  # or tox -e py37,py38,py39
+  tox  -e py
 
 
 Version Scheme
@@ -20,196 +20,6 @@ This basically means that releases will look like `0.3`, `0.3.1`,
 `0.3.1.dev0`.
 
 
-How to Release
-=================
-
-
-Preparation
------------------
-
-1. Get yourself an account at PyPI_ and TestPyPI_. Fill both
-   credentials in your `~/.pypirc` file, as `described in the Python
-   Wiki <https://wiki.python.org/moin/TestPyPI>`_.
-
-   * In difference to that description, list `pypitest` *first*. This
-     will make `zest.releaser` push the release there first giving you
-     a chance for last minute fixes.
-
-2. Install `docutils` and `zest.releaser`, a helper for automating
-   releasing a Python project::
-
-     pip install --user docutils zest.releaser
-
-
-Full Release Process
----------------------
-
-1. Prepare (see above).
-
-2. Implement and close all issues and pull requests in a specific
-   milestone.
-
-3. Ensure everything relevant is committed and tested. ``git stash``
-   your local changes which should not go into the release.
-
-4. Be sure that the current code passes tests locally::
-
-     tox -e py37,py38,py39
-
-5. Be sure `CI tests
-   <https://github.com/pytest-dev/unittest2pytest/actions>`_ pass.
-
-
-Now we start with the main release process.
-
-6. Set shell variables to be able to copy-and-paste the remaining
-   snippets, e.g.::
-
-      version=0.3
-      prev_version=0.2
-
-7. Create the **release branch**::
-
-      git checkout -b release/$version
-
-8. **Update versions** in source-code, Changelog, etc.::
-
-      prerelease # zest.releaser command
-
-   This will
-
-   - ask you a few questions - required version, etc.
-   - remove `.devN` from the version string
-   - update date and version in `CHANGES.rst`
-
-9. Update **``CHANGES.rst``** and **``AUTHORS``**.
-
-    Where to look for possible changes? You can look in pull requests,
-    issues, commits, mailing list or even the tool's cli options
-    (new/removed options).
-
-    Authors should be updated based on merged pull requests::
-
-       git shortlog --numbered --summary --email v${prev_version}..HEAD
-
-    a. Check if the files are valid reStructuredText by running::
-
-        rst2html CHANGES.rst > /tmp/CHANGES.html
-        xdg-open /tmp/CHANGES.html  # opens file in your web-browser
-
-    b. If everything is fine, commit::
-
-        git commit -m "Update CHANGES and AUTHORS for release $version" \
-           CHANGES.rst AUTHORS.txt
-
-
-10. In the **README**, update the versions in the badge-images and
-    related links.
-
-    a. Verify the result be running::
-
-         git diff --color-words='.' README.rst
-
-    b. Again, check if the files are valid reStructuredText by running::
-
-        rst2html README.rst > /tmp/README.html
-        xdg-open /tmp/README.html  # opens file in your web-browser
-
-    c. If everything is fine, commit::
-
-        git commit -m 'Update versions in README.' README.rst
-        README_CHANGE=$(git rev-parse --short HEAD) # remember this commit
-
-11. Adjust whatever else is required for the release *now*.
-
-
-12. Complete the release:
-
-    a. Merge into branch `master`::
-
-          git checkout master
-          git merge --no-ff -X theirs -m "Finished release $version." \
-             release/$version
-
-    b. In case of a merge-conflict, resolve it using::
-
-	 git gui # In the context-menu select "Use Local Version"
-	 git commit -m "Release $version."
-
-
-13. Run the release script ``release`` and it will do:
-
-    - create a signed tag for the released version
-    - create and sign source archives
-    - uploads them to PyPI
-
-    ::
-
-      release # zest.releaser command
-
-    Submit to `testpypi` first! You can not change any file after
-    you've uploaded it to PyPI!
-
-14. Push the  changes::
-
-       git push --follow-tags origin master
-
-15. Create release on GitHub:
-
-    a. Go to the `unittest2pytest release page
-       <https://github.com/pytest-dev/unittest2pytest/releases>`_
-
-    b. Edit the latest `tag` details.
-
-    c. Copy there changelog for the current release. This should look
-       like `this one
-       <https://github.com/pytest-dev/unittest2pytest/releases/tag/v0.3>`_
-
-    d. Upload the `.tar.gz`- and `.zip`-archives and GPG-signatures
-       that where uploaded to |unittest2pytest@PyPI|_
-
-       Note: If you are using stuff like RequestBlocker or NoScript in
-       your web-browser, mind to allow some additional access.
-
-
-Now we are going to perform some **post-release** steps:
-
-16. Forward the release-branch to master and check it out::
-
-       git checkout master
-       git branch -f release/$version master
-       git checkout release/$version
-
-17. Revert the version-related to the README (using the commit we
-    remembered earlier)::
-
-      git revert $README_CHANGE
-
-18. Run the release script ``postrelease``::
-
-      postrelease # zest.releaser command
-
-    This will
-
-    - increment version string for a new release: `3.0 -> 3.1.dev0`
-    - prepare `CHANGES.rst` for the next release.
-
-    You need to manually check the `README` and the version in
-    `CHANGES`.
-
-19. Merge into branch `develop`::
-
-      git checkout develop
-      git merge --no-ff -m "Finished release $version." release/$version
-
-20. Check the diffs: it should only be version related stuff::
-
-      git diff origin/develop
-
-21. Push the  changes and delete the local release branch::
-
-       git push --follow-tags origin develop master
-       git branch -d release/$version
 
 
 .. _PyPI: https://pypi.python.org/

diff --git a/MANIFEST.in b/MANIFEST.in
@@ -1,4 +1,4 @@
-include CHANGES.rst
+include CHANGELOG.rst
 include COPYING-GPLv3.txt
 include README.rst
 

diff --git a/README.rst b/README.rst
@@ -8,7 +8,7 @@ Helps converting unittest test-cases to pytest
 
 :Author:    Hartmut Goebel <[email protected]>
 :Version:   0.5.dev0
-:Copyright: 2015-2019 by Hartmut Goebel
+:Copyright: 2015 by Hartmut Goebel
 :Licence:   GNU Public Licence v3 or later (GPLv3+)
 :Homepage:  https://github.com/pytest-dev/unittest2pytest
 

diff --git a/RELEASING.rst b/RELEASING.rst
@@ -0,0 +1,37 @@
+=========================
+Releasing unittest2pytest
+=========================
+
+This document describes the steps to make a new ``unittest2pytest`` release.
+
+Version
+-------
+
+``master`` 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:
+
+#. Create a new branch named ``release-X.Y.Z`` from the latest ``main``.
+
+#. Update the ``CHANGELOG.rst`` file with the new release information.
+
+#. Commit and push the branch to ``upstream`` and open a PR.
+
+#. Once the PR is **green** and **approved**, start the ``deploy`` workflow:
+
+   .. code-block:: console
+
+        gh workflow run deploy.yml -R pytest-dev/unittest2pytest --ref release-VERSION --field version=VERSION
+
+   The PR will be automatically merged.