👷 Use GitHub App token for workflow that updates MQT Core

[denialhaag]

Description

This PR changes the reusable update-mqt-core workflow so that it creates the PR using a GitHub App token.

This change requires an update in the repositories using the workflow. For an exemplary PR updating the usage, see munich-quantum-toolkit/qmap#689.

For more information on using secrets in reusable workflows, see the documentation.

Checklist:

• The pull request only contains commits that are focused and relevant to this change.
• I have added appropriate tests that cover the new/changed functionality.
• I have updated the documentation to reflect these changes.
• I have added entries to the changelog for any noteworthy additions, changes, fixes or removals.
• I have added migration instructions to the upgrade guide (if needed).
• The changes follow the project's style guidelines and introduce no new warnings.
• The changes are fully tested and pass the CI checks.
• I have reviewed my own code changes.

[denialhaag]

@burgholzer, which other repositories use this reusable workflow and need an update? 🤔

[burgholzer]

This looks great. Many thanks.
I just tagged this with the "minor" label, because it will require updates in consuming workflows.

Would you mind adding a respective Changelog entry and an upgrade guide notice?

[burgholzer]

@burgholzer, which other repositories use this reusable workflow and need an update? 🤔

Basically all C++ repositories using mqt-core. That should be

• QCEC
• QMAP
• DDSIM
• DDVIS
• SyReC
• Debugger

[denialhaag]

This looks great. Many thanks. I just tagged this with the "minor" label, because it will require updates in consuming workflows.

Would you mind adding a respective Changelog entry and an upgrade guide notice?

Done!

[burgholzer]

Thanks. Just a minor suggestion for the upgrade guide note. I'll quickly apply that and then this should be good to go.

Let's briefly take the time to think about whether it would make sense to add further PRs before the next release or whether we should just prepare a new release right now.

[denialhaag]

Let's briefly take the time to think about whether it would make sense to add further PRs before the next release or whether we should just prepare a new release right now.

I think it makes sense to prepare a release now and then wait for the Renovate PRs to include the necessary changes. 🤔

[burgholzer]

Let's briefly take the time to think about whether it would make sense to add further PRs before the next release or whether we should just prepare a new release right now.

I think it makes sense to prepare a release now and then wait for the Renovate PRs to include the necessary changes. 🤔

Yeah. In that case, I think it makes sense to already prepare that as part of this PR and release right after merging.
That mainly involves adding dedicated sections for the new release in both guides.

[denialhaag]

Let's briefly take the time to think about whether it would make sense to add further PRs before the next release or whether we should just prepare a new release right now.

I think it makes sense to prepare a release now and then wait for the Renovate PRs to include the necessary changes. 🤔

Yeah. In that case, I think it makes sense to already prepare that as part of this PR and release right after merging. That mainly involves adding dedicated sections for the new release in both guides.

Perfect! The most recent commit should include the necessary changes. 🤔

[burgholzer]

LGTM 👍🏼
I'll merge this and trigger the release as soon as the release drafter has run on the main branch.