May 10, 2021 · Apr 28, 2021
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
 name: Release

 on:
  schedule:
    - cron: '0 0 28 * *'  # Monthly auto-release
  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
  -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
   docker rm -f gitlab-test
   docker rm -f gitlab-runner-test

 Releases
 --------

 A release is automatically published once a month on the 28th if any commits merged
 to the main branch contain commit message types that signal a semantic version bump
 (``fix``, ``feat``, ``BREAKING CHANGE:``).

 Additionally, the release workflow can be run manually by maintainers 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
 [tool.semantic_release]
 version_variable = "gitlab/__version__.py:__version__"
 commit_subject = "chore: release v{version}"
 commit_message = ""
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1,19 @@
		name: Release

		on:
		schedule:
		- cron: '0 0 28 * *' # Monthly auto-release
		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 }}
Original file line number	Diff line number	Diff line change
Expand Up		@@ -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:
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -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 is automatically published once a month on the 28th if any commits merged
		to the main branch contain commit message types that signal a semantic version bump
		(``fix``, ``feat``, ``BREAKING CHANGE:``).

		Additionally, the release workflow can be run manually by maintainers 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).
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1,4 @@
		[tool.semantic_release]
		version_variable = "gitlab/__version__.py:__version__"
		commit_subject = "chore: release v{version}"
		commit_message = ""