Fix bug when multiple installations are available and scope is not specified #82
+20
−21
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The way the action is currently handling fetching the installation id of an App is problematic:
In case a user has not specified the scope, the action will fetch the first page of all the installations (default is 30 results per page) and simply pick the first installation of these. This is problematic for the simple reason that the owner of the repository where the workflow is running might not be the only organization/user where the App is installed.
The bug is easy to reproduce, create a GitHub App and install it on two different organizations or users. Without specifying the scope, the action will always fetch the installation access token for where you installed the GitHub App last, that surely cannot be the intended behavior.
Additionally, even if scope is specified, the
appOctokit.apps.listInstallations
call will fetch the first 30 results, if the GitHub App is installed in more than 30 organizations/users, it is possible the owner specified in the scope is not among the first 30 results returned. Pagination would solve this but a much simpler way exists.The pull request is aimed at fixing that behavior. The default scope is the owner of the repository where the workflow is running. This is a more reliable way of fetching the installation id.