This section details on the original issue you should resolve

<issue_title>write permission is conditionally needed by release-drafter</issue_title>
<issue_description>The cpp-linter repo has 2 workflows that call into the reusable workflow, .github/workflows/release-drafter.yml:

1. cpp-linter/cpp-linter/.github/workflows/labeler.yml requires

   permissions:
     contents: read
     pull-requests: write

2. cpp-linter/cpp-linter/.github/workflows/release-drafter.yml; requires

   permissions:
     contents: write
     pull-requests: read

While the reusable workflow demands write permission regardless of calling context:

Proposal

The permissions map cannot be dynamically set.

# THIS WILL NOT WORK!
permissions:
  contents: ${{ inputs.mk-labels && 'read' || 'write' }}
  pull-requests: ${{ inputs.mk-draft-release && 'read' || 'write' }}

This means we need 2 separate reusable workflows for each calling context:

• To auto-label PRs
• To draft (or update a drafted) release

Because the reusable workflow is just 1 step, I'm inclined to just copy that 1 step into the calling workflows' yml and modify the permissions as needed.

Or use git-cliff + gh-cli

In the cpp-linter-rs repo, I use a script (written in python) to

1. Bump the version according to inputs.component. In rust this requires altering the Cargo.toml manifest. In python we would only need to calculate the version based on the last tag.
2. Use git-cliff with the new version number to generate release notes (used in the final step 4). This step also regenerates the entire CHANGELOG.md in repo root.
3. Use git to push any metadata file changes. The step is not required where setuptools-scm automatically sets the package version based on git describe --tags (or similar).
4. Use gh-cli (requires a PAT with permissions: {contents: write}) to publish a release, which inherently creates a new tag that triggers build/deploy CI workflows.

[!caution]
step 4 requires a PAT instead of the generic/default secrets.GITHUB_TOKEN because CI triggers are ignored for events caused by "github-actions[bot]".

This might seem overly complicated, but it provides much better flexibility and does not surrender security to third-party software that we don't control/understand.

</issue_description>

<agent_instructions>see #47 (comment)</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Auto label doesn't work

I think we need to use a separate config just for that auto-label feature (during a PR event).
And, for some reason, the release-drafter action tries to create/update a drafted release during a PR event, before it is merged (?!).

There must be a better way to auto label PR. Personally, I could do it with nushell and gh-cli...

Drafting releases

If releases are only focused on PRs, then commits pushed directly to main will not show up in the release notes 👎🏼.

I understand that release-drafter relies solely on PR/issue labels to categorize release notes. But release notes can be generated in a number of different ways.
I know git-cliff can use both PR labels and conventional-commit titles to categorize changes. Git-cliff can even "guess" the next version tag based on unreleased changes, but I don't often use that feature.

Originally posted by @2bndy5 in cpp-linter/cpp-linter#154 (comment)

I'm literally putting this together right now. I'm writing it in a way that should be applicable to any cpp-linter repos (as a reusable workflow)... But I want to test it first in cpp-linter because we already have a pending release.

[!TIP]
The cpp-linter-rs repo is already doing this because there are multiple package ecosystems being used for deployments. See bump-n-release workflow.</comment_new>
<comment_new>@shenxianpeng
There must be a better way to auto label PR. Personally, I could do it with nushell and gh-cli...

I agree that the label does not work well. maybe we could try to use [Continuous AI](ht...