Python publish workflow

.github/workflows/python-publish-to-pypi.yaml

@@ -0,0 +1,39 @@
+name: Publish Python to Pypi
+
+on:
+  push:
+    tags:
+      - python-*
+
+jobs:
+  publish-python-to-pypi:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v2
+
+    - uses: actions/setup-python@v2
+      with:
+        python-version: '3.7'
+
+    - name: Install build & twine
+      run: pip install twine build
+
+    - name: Build wheels
+      working-directory: ./python/sqlcommenter-python
+      run: python -m build
+
+    - name: Publish to TestPyPI
+      working-directory: ./python/sqlcommenter-python
+      env:
+        TWINE_USERNAME: '__token__'
+        TWINE_PASSWORD: ${{ secrets.test_pypi_token }}
+      run: |
+        twine upload --repository testpypi --skip-existing --verbose dist/*
+
+    - name: Publish to PyPI
+      working-directory: ./python/sqlcommenter-python
+      env:
+        TWINE_USERNAME: '__token__'
+        TWINE_PASSWORD: ${{ secrets.pypi_password }}
+      run: |
+        twine upload --skip-existing --verbose dist/*

.github/workflows/python-tests.yaml

@@ -33,7 +33,7 @@ jobs:
         with:
           python-version: ${{ env[matrix.python-version] }}
       - name: Install tox
-        run: pip install -U tox-factor
+        run: pip install tox tox-gh-actions
       - name: run tox
         run: tox -e '${{ matrix.python-version }}-{django21,django22,django30,django31,django32,psycopg2,flask,generic,sqlalchemy}'
         working-directory: ./python/sqlcommenter-python

python/sqlcommenter-python/RELEASE.md

@@ -0,0 +1,41 @@
+# Releases
+
+This page describes the release process. The release will be done by the maintainers.
+
+## How to cut an individual release
+
+### Branch management and versioning strategy
+
+We use [Semantic Versioning](https://semver.org/).
+
+We maintain a separate branch for each  release, named `release-<major>.<minor>`, e.g. `release-1.1`, `release-2.0`.
+
+The usual flow is to merge new features and changes into the master branch and to merge bug fixes into the latest release branch. Bug fixes are then merged into master from the latest release branch. The master branch should always contain all commits from the latest release branch. As long as master hasn't deviated from the release branch, new commits can also go to master, followed by merging master back into the release branch.
+
+If a bug fix got accidentally merged into master after non-bug-fix changes in master, the bug-fix commits have to be cherry-picked into the release branch, which then have to be merged back into master. Try to avoid that situation.
+
+Maintaining the release branches for older minor releases happens on a best effort basis.
+
+### Prepare your release
+
+This helps ongoing PRs to get their changes in the right place, and to consider whether they need cherry-picked.
+
+1. Make a PR to update `CHANGELOG.md` on master
+   - Add a new section for the new release so that "unreleased" is blank and at the top.
+   - New section should say "## x.y.0 - release date".
+2. Change the release version in `setup.py` file. 
+3. This PR will get merged.
+
+### Create release branch
+
+To prepare release branch, first create new release branch (release-X.Y) in repository from master commit of your choice
+
+### Publish a stable release
+
+To publish a stable release:
+
+1. Do not change the release branch directly; make a PR to the release-X.Y branch with VERSION and any CHANGELOG changes.
+2. After merging your PR to release branch, `git tag` the new release from release branch.
+3. Tag should be prefixed with `python-`
+4. Once the release occurs `publish-python-to-pypi` workflow job will get executed and will publish the library to testpypi and pypi
+5. When build succeeds, merge the release branch `release-x.y` to `master`