Gets a random installation's token, not one that works for the current repo

[RobinDaugherty]

Steps to Reproduce

1. Create GitHub App
2. Install the App on a repository
3. Install the App on a second repository ("number-two")
4. Add app ID and private key to repo "number-two" secrets
5. Add workflow that uses this action with those secrets to get an access token and uses it to perform an action on the "number-two" repository (e.g. create a deployment)

Expected Result

Access token works on the "number-two" repository

Actual Result

API returns 404 error because the access token does not have permissions on the "number-two" repository.

This is because this action returns a semi-random installation's token.
It does not look at the Actions environment to get the current repository, or have inputs to determine which repository should be set.

The input scope looks at the installation information, apparently to match on who installed the app, which seems to be a very limited way to match the app.

For an example Action that does this correctly, see https://github.com/tibdex/github-app-token

[jorsmatthys]

EDIT:
Never mind, our use-case was different from the one above, the undocumented scope parameter does the job perfectly for us (scope: <name-of-the-org-the-app-is-installed-on>, so I think the only thing that would need to happen is adding that one to the documentation for our scenario.

We are running into the same issue when using this action with an app installed on 2 organizations. For maximum flexibility it would be handy if:

• The installation id could be provided through an extra parameter app_installation_id
• If nothing is provided, you could perhaps assume the organization/account the repo is part of

I think just having the parameter would be great, the fallback is really just nice to have (you could keep the current behavior there perhaps as that would keep working perfectly for apps installed on only one organization).