chore(ci): automate releaseschore/automate-releases

4 files changed, 47 insertions, 15 deletions

diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
new file mode 100644
index 0000000..e0554c6
--- /dev/null
+++ b/.github/workflows/release.yml
@@ -0,0 +1,19 @@
+name: Release
+
+on:
+  schedule:
+    - cron: '0 0 * * 1'   # Auto-release every Monday at midnight UTC
+  workflow_dispatch:      # Manual trigger for quick fixes
+
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v2
+      with:
+        fetch-depth: 0
+    - name: Python Semantic Release
+      uses: relekang/python-semantic-release@master
+      with:
+        github_token: ${{ secrets.GITHUB_TOKEN }}
+        pypi_token: ${{ secrets.PYPI_TOKEN }}
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 64e42e2..72d81d2 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -4,21 +4,6 @@ stages:
   - deploy
   - deploy-latest
 
-deploy:
-  stage: deploy
-  script:
-    - pip install -U setuptools wheel twine
-    - python setup.py sdist bdist_wheel
-    # test package
-    - python3 -m venv test
-    - . test/bin/activate
-    - pip install -U dist/python_gitlab*.whl
-    - gitlab -h
-    - deactivate
-    - twine upload --skip-existing -u $TWINE_USERNAME -p $TWINE_PASSWORD dist/*
-  only:
-    - tags
-
 deploy_image:
   stage: deploy
   image:
diff --git a/README.rst b/README.rst
index 9e8c212..ed90124 100644
--- a/README.rst
+++ b/README.rst
@@ -213,3 +213,27 @@ To cleanup the environment delete the container:
    docker rm -f gitlab-test
    docker rm -f gitlab-runner-test
 
+Releases
+--------
+
+A release workflow is triggered every Monday and automatically creates a new
+release if any commits merged to the main branch contain commit message scopes
+that would result in a semantic version bump.
+
+Additionally, the release workflow can be run manually to publish urgent fixes,
+either on GitHub or using the ``gh`` CLI with ``gh workflow run release.yml``.
+
+**Note:** As a maintainer, this means you should carefully review commit messages
+used by contributors in their pull requests. If scopes such as ``fix`` and ``feat``
+are applied to trivial commits not relevant to end users, it's best to squash their
+pull requests and summarize the addition in a single conventional commit.
+This avoids triggering incorrect version bumps and releases without functional changes.
+
+The release workflow uses `python-semantic-release
+<https://python-semantic-release.readthedocs.io>`_ and does the following:
+
+* Bumps the version in ``__version__.py`` and adds an entry in ``CHANGELOG.md``,
+* Commits and tags the changes, then pushes to the main branch as the ``github-actions`` user,
+* Creates a release from the tag and adds the changelog entry to the release notes,
+* Uploads the package as assets to the GitHub release,
+* Uploads the package to PyPI using ``PYPI_TOKEN`` (configured as a secret).
diff --git a/pyproject.toml b/pyproject.toml
new file mode 100644
index 0000000..eda0a12
--- /dev/null
+++ b/pyproject.toml
@@ -0,0 +1,4 @@
+[tool.semantic_release]
+version_variable = "gitlab/__version__.py:__version__"
+commit_subject = "chore: release v{version}"
+commit_message = ""