Problem
The config requires a hard-coded installation_id for every org and repo entry. It is error-prone and awkward to obtain, especially for repo-scoped entries where the user has to open the GitHub App settings page and read the id out of the URL. The org/repo/user name is already present in the config, so the installation_id is redundant.
Proposal
When auth uses a GitHub App, resolve the installation id automatically from the configured name and make the installation_id field optional.
The GitHub REST API exposes the installation for a given account/repo directly (authenticated with the App JWT):
- Org:
GET /orgs/{org}/installation
- Repo:
GET /repos/{owner}/{repo}/installation
- User:
GET /users/{username}/installation
Each returns the installation object, including its id.
Behavior
- If
installation_id is set, use it as-is (backwards compatible).
- If omitted, resolve it at startup from the org/repo name via the endpoint above.
- Fail fast with a clear error if the App is not installed on that account/repo (the error should name the org/repo so it is diagnosable without source code).
This removes a manual, error-prone config step.
Problem
The config requires a hard-coded
installation_idfor every org and repo entry. It is error-prone and awkward to obtain, especially for repo-scoped entries where the user has to open the GitHub App settings page and read the id out of the URL. The org/repo/user name is already present in the config, so theinstallation_idis redundant.Proposal
When auth uses a GitHub App, resolve the installation id automatically from the configured name and make the
installation_idfield optional.The GitHub REST API exposes the installation for a given account/repo directly (authenticated with the App JWT):
GET /orgs/{org}/installationGET /repos/{owner}/{repo}/installationGET /users/{username}/installationEach returns the installation object, including its
id.Behavior
installation_idis set, use it as-is (backwards compatible).This removes a manual, error-prone config step.