Automated Release Build and Publishing

[rolweber]

This PR introduces a GitHub Actions workflow. When you publish a new GitHub release, this workflow...

1. takes the version number from the release tag, for example "v1.4.0dev1".
2. injects that version into setup.py and pypyodbc.py.
3. builds a source archive and a py3 wheel, which is cross-platform.
   • The version number is part of the file names.
4. uploads both artifacts to the GitHub release.
5. depending on the version number...
   1. If the version contains "dev", as in the example above, nothing further happens.
      • For developmental releases.
      • Example release and build log.
   2. If the version contains "a" or "b", for example v1.4.0a2, both artifacts are published to Test PyPI.
      • For alpha and beta pre-releases.
      • Example release and build log.
   3. Otherwise, both artifacts are published to PyPI proper.
      • For rc and final releases.
      • Example release and build log. Upload to PyPI failed intentionally, as I don't have permission to yank or delete a release. But the upload script was tested with a dummy project against PyPI, too.

The major change to the codebase is that I've removed the "next" version number from pypyodbc.py and instead put a placeholder there, and into setup.py. That placeholder is searched and replaced by the version injection script. @braian87b if you move the versions to another file, for example from setup.py to setup.cfg, you'll have to update .github/scripts/inject-version.sh accordingly. The line with the sed command at the end. I had to remove the import of pypyodbc from setup.py to make the build work, and instead duplicated the version placeholder. On import, pypyodbc tries to load libodbc. But that library may not available in the build environment, where setup.py is evaluated. With the version number being injected automatically, there's no concern about differing version numbers in two places anymore. I removed the test_version functions from two files. It would only test the placeholder, but not the actual version that's injected at build time.

There are some moving pieces in the workflow. It uses GitHub's latest Ubuntu image, where the python3 version may change. It installs the latest version of build for building the packages, and of twine for uploading to (test) PyPI. If there is a new release after a longer break, I recommend to first make a developmental release (for testing the build step), then an alpha release (for testing the publishing step).