Summary
The backport-base.yml reusable workflow currently hardcodes the use of github.token for PR creation (via actions/github-script) and gh CLI operations. There is no way for callers to provide a custom token.
Problem
Organizations like microsoft have disabled the Allow GitHub Actions to create and approve pull requests setting at the enterprise level. This means github.token can no longer create pull requests. Repositories in these orgs need to use a GitHub App installation token as a workaround, but the backport reusable workflow doesn't accept a custom token.
The dotnet/aspire repository (now at microsoft/aspire) uses this reusable workflow and is affected by this restriction.
Proposed Change
Add an optional secrets input to the reusable workflow so callers can provide a custom token:
on:
workflow_call:
secrets:
github_token:
required: false
Then use it in the workflow steps with a fallback to the default:
- uses: actions/github-script@v7
with:
github-token: ${{ secrets.github_token || github.token }}
And for the gh CLI:
env:
GH_TOKEN: ${{ secrets.github_token || github.token }}
This is fully backward-compatible — callers that don't pass the secret will continue using github.token as before.
Context
- Enterprise-level setting: Disabled the setting for: Allow GitHub Actions to create and approve pull requests
- GitHub's recommended workaround is to use a GitHub App installation token
- The backport workflow is the only external dependency blocking
microsoft/aspire from fully migrating to App-based tokens
Summary
The
backport-base.ymlreusable workflow currently hardcodes the use ofgithub.tokenfor PR creation (viaactions/github-script) andghCLI operations. There is no way for callers to provide a custom token.Problem
Organizations like
microsofthave disabled the Allow GitHub Actions to create and approve pull requests setting at the enterprise level. This meansgithub.tokencan no longer create pull requests. Repositories in these orgs need to use a GitHub App installation token as a workaround, but the backport reusable workflow doesn't accept a custom token.The
dotnet/aspirerepository (now atmicrosoft/aspire) uses this reusable workflow and is affected by this restriction.Proposed Change
Add an optional
secretsinput to the reusable workflow so callers can provide a custom token:Then use it in the workflow steps with a fallback to the default:
And for the
ghCLI:This is fully backward-compatible — callers that don't pass the secret will continue using
github.tokenas before.Context
microsoft/aspirefrom fully migrating to App-based tokens