Support tokens with access to custom repositories and user/organization accounts
Closed this issue ยท 5 comments
The use cases we want to cover is
- By default, create a token scoped to the current repository
- Allow to scope to a set of repositories by names for the current owner
- Allow to scope to a different owner (all installation repositories)
- Allow to scope to a set of repositories by names for a different owner
Our API idea is
- uses: actions/create-github-app-token@v1
id: app-token
with:
app_id: ${{ vars.APP_ID }}
private_key: ${{ secrets.PRIVATE_KEY }}
owner: some-owner
repositories: some-repo1,some-repo2
Both owner
and repositories
would be optional, and one can be set to the other. owner
defaults to the current repository owner, and repositories defaults to the current repository name.
Under the GitHub Enterprise Cloud setup, we are often required to access repositories under multiple organizations. It would be great if you consider covering the checkout use case like these:
# Checkout orgA/repoA and orgB/repoB
- uses: actions/create-github-app-token@v1
id: app-token
with:
app_id: ${{ vars.APP_ID }}
private_key: ${{ secrets.PRIVATE_KEY }}
repositories: orgA/repoA, orgB/repoB
- uses: actions/checkout@v4
with:
repository: 'orgA/repoA'
token: ${{ steps.app-token.outputs.token }}
- uses: actions/checkout@v4
with:
repository: 'orgB/repoB'
token: ${{ steps.app-token.outputs.token }}
# Checkout the current repository which has orgA/repoA and orgB/repoB as submodule
- uses: actions/create-github-app-token@v1
id: app-token
with:
app_id: ${{ vars.APP_ID }}
private_key: ${{ secrets.PRIVATE_KEY }}
repositories: ${{ github.repository }}, orgA/repoA, orgB/repoB
- uses: actions/checkout@v4
with:
submodules: true
token: ${{ steps.app-token.outputs.token }}
Your idea won't work, unfortunately.
For one, an installation access token can by design only access a single account (GitHub user or organization account). There cannot be a single token that has access across multiple organizations.
I did however run into this requirement myself, and I can think of a workaround, but let's discuss this in a separate issue as it's out of scope for this one
This is an important feature for some of my use cases as well. Notably I need to be able to remove the repository restriction for automation which works across the organization.
could we get this supported please, would be real useful,
thanks!
๐ This issue has been resolved in version 1.3.0 ๐
The release is available on GitHub release
Your semantic-release bot ๐ฆ๐