fix(ci): use commitizen bot to push tags and commits

.github/workflows/bumpversion.yml

@@ -14,12 +14,22 @@ jobs:
       contents: write
       actions: write
     steps:
+      - uses: actions/create-github-app-token@v3
+        id: app-token
+        with:
+          app-id: ${{ vars.APP_ID }}
+          private-key: ${{ secrets.PRIVATE_KEY }}
       - name: Check out
         uses: actions/checkout@v6
         with:
+          token: ${{ steps.app-token.outputs.token }}
           fetch-depth: 0
           fetch-tags: true
+          persist-credentials: false
       - uses: commitizen-tools/setup-cz@main
+        with:
+          git-user-name: "${{ steps.app-token.outputs.app-slug }}[bot]"
+          git-user-email: "${{ steps.get-user-id.outputs.user-id }}+${{ steps.app-token.outputs.app-slug }}[bot]@users.noreply.github.com"
       - id: bump-version
         run: |
           cz bump --yes
@@ -39,9 +49,3 @@ jobs:
           NEW_VERSION_TAG: ${{ steps.bump-version.outputs.new_version_tag }}
         run: |
           gh release create "${NEW_VERSION_TAG}" --notes-file .changelog.md
-      - name: trigger other workflow
-        env:
-          GH_TOKEN: ${{ github.token }}
-        run: |
-          gh workflow run pythonpublish.yml \
-            -f "version=${{ steps.bump-version.outputs.new_version_tag }}"

.github/workflows/pythonpublish.yml

@@ -1,20 +1,10 @@
 name: Upload Python Package
 
-# With the current configuration this workflow will be
-# triggered via `workflow_dispatch` in `bumpversion.yml`.
-# We leave the `push.tags` trigger to allow for manual releases
-# in case we need to bump locally, and we actively push the tag.
-# The PERSONAL_ACCESS_TOKEN is no longer needed as we use the OIDC token instead.
-# We favor this approach because it requires less steps to set up and is more secure.
+# The tag is now triggered by the Github App: CommitizenBot
 on:
   push:
     tags:
       - "v*"
-  workflow_dispatch:
-    inputs:
-      version:
-        description: "Version to trigger"
-        required: true
 
 jobs:
   deploy:
@@ -27,7 +17,7 @@ jobs:
       - uses: actions/checkout@v6
         with:
           fetch-depth: 0
-          ref: ${{ inputs.version || github.ref_name }}
+          ref: ${{ github.ref_name }}
       - name: Set up Python
         uses: astral-sh/setup-uv@v7
       - name: Build

docs/config/option.md

@@ -7,9 +7,9 @@ Name of the committing rules to use. What we generally call the **commit convent
 - Type: `str`
 - Default: `"cz_conventional_commits"`
 - Options
-  - `cz_conventional_commits`: uses [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/)
-  - `cz_jira`: jira [smart commits](https://support.atlassian.com/bitbucket-cloud/docs/use-smart-commits/)
-  - `cz_customize`: (**not recommended**) customize the convention directly in the `TOML` file under `[tool.commitizen.customize]`, read [Customize in configuration file](../customization/config_file.md) for more. There's a plan to provide a different functionality.
+    - `cz_conventional_commits`: uses [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/)
+    - `cz_jira`: jira [smart commits](https://support.atlassian.com/bitbucket-cloud/docs/use-smart-commits/)
+    - `cz_customize`: (**not recommended**) customize the convention directly in the `TOML` file under `[tool.commitizen.customize]`, read [Customize in configuration file](../customization/config_file.md) for more. There's a plan to provide a different functionality.
 
 You can write your own convention, and release it on PyPI, check [Customizing through a Python class](../customization/python_class.md).