This is a follow up to #4 (comment)

@kmaehashi had posted the following request here

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 }}

Unfortunately, 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.

But I've run into this requirement before and I see a possible workaround that would require an additional action and the user of matrix.

1. Say there was an action like actions/get-app-installation-ids, it would take app_id and private_key as arguments, and optionally a list of logins to filter down the installations. The action would have installation_ids and installation_logins outputs.
2. That output could be used to dynamically set strategy.matrix in a second job, so all steps would be run for each of the installation IDs
3. In the second job, actions/create-github-app-token could be used to create an installation access token for that particular installation

I'm however not sure how we could filter down to specific repositories across multiple organizations. I'd need to experiment myself to see what's possible. Maybe the actions/get-app-installation-ids could take an argument like you suggest (say repositories: orgA/repoA, orgA/repoB, orgB/repoC) and then have a nested output like this: [["orgA", "repoA, repoB"],["orgB", "repoC"]] which we could could iterate through using the matrix and then split out the items like ["orgA", "repoA, repoB"] into owner: orgA, repositories: repoA, Repo B