This pull request adds support for generating GitHub App installation
tokens for enterprise-level installations.
### What changed
- Added a new `enterprise` input to `action.yml`.
- Wired `enterprise` through `main.js` and `lib/main.js`.
- Added validation so `enterprise` cannot be combined with `owner` or
`repositories`.
- Implemented enterprise installation lookup using the direct GitHub API
route `GET /enterprises/{enterprise}/installation`, then used the
returned installation ID to mint an installation token through
`@octokit/auth-app`.
- Updated `README.md` with enterprise installation usage and input
documentation.
- Updated `dist/main.cjs` for the bundled action.
- Shared token creation retry behavior across repository, owner, and
enterprise paths so server errors and transient network errors are
retried, while client errors fail immediately.
### Tests
Added focused test coverage for:
- enterprise token creation
- enterprise token creation with explicit permissions
- enterprise installation not found
- mutual exclusivity with `owner`
- mutual exclusivity with `repositories`
- owner installation client errors are not retried
- transient network errors are retried during token creation
### Notes
- This keeps the existing repository-scoped token behavior unchanged.
- Owner, repository, and enterprise token creation now share the same
retry policy: server errors and recognized transient network errors are
retried, while client errors fail immediately. This intentionally fixes
the previous owner-path behavior that retried client errors.
Refs:
-
https://github.blog/changelog/2025-07-01-enterprise-level-access-for-github-apps-and-installation-automation-apis/
-
https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#get-an-enterprise-installation-for-the-authenticated-app
---------
Co-authored-by: Parker Brown <17183625+parkerbxyz@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
When `client-id` (or the deprecated `app-id`) resolves to an empty
string, for example because a secret or variable is not available in the
workflow context, the error message from `@octokit/auth-app` is not very
helpful:
```
[@octokit/auth-app] appId option is required
```
A validation check was added recently to catch this earlier, but its
message could be more informative:
```
Either 'client-id' or 'app-id' input must be set
```
This updates the message to clarify that the value resolved to empty and
nudges users toward checking their secret or variable availability:
```
The 'client-id' input must be set to a non-empty string. If using a secret or variable, ensure it is available in this workflow context.
```
Closes#249
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
GitHub now recommends using a GitHub App's Client ID for authentication.
This PR adds a first-class `client-id` input, keeps `app-id` available
for compatibility, and makes the migration path explicit in both runtime
behavior and documentation.
### Action inputs
- Adds a new `client-id` input
- Removes `required` from `app-id`
- Marks `app-id` as deprecated in `action.yml`
### Runtime behavior
- Updates input parsing to prefer `client-id`
- Falls back to `app-id` for existing workflows
- Adds a clear error when neither `client-id` nor `app-id` is provided
### Docs
- Updates the README to recommend `client-id`
- Switches usage examples to `client-id`
- Documents that `app-id` is deprecated and that `client-id` takes
precedence if both are set
### Regression coverage
- Adds a focused test proving a client-ID-shaped value works through the
new `client-id` input
- Adds coverage for the missing-ID validation path
- Updates snapshots to lock in the new metadata and runtime behavior
### Resulting usage
Users can migrate to the new input name directly:
```yaml
- uses: actions/create-github-app-token@v3
with:
client-id: ${{ vars.GITHUB_APP_CLIENT_ID }}
private-key: ${{ secrets.GITHUB_APP_PRIVATE_KEY }}
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: parkerbxyz <17183625+parkerbxyz@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
AVA stores snapshots in a binary format (`.snap`), which produces no
meaningful diffs and bloats Git history. This replaces AVA with the
built-in `node:test` module, whose snapshot support generates
human-readable text files that are easy to diff and review in pull
requests.
The migration also replaces `@sinonjs/fake-timers` and `execa` with
Node.js built-ins (`node:test` mock timers and `node:child_process`),
removing three dev dependencies total.
- **`tests/index.js`**: Rewritten to use `node:test` with a custom
snapshot serializer that renders strings with actual newlines. Uses
subtests for labeled `stderr`/`stdout` snapshots, and only snapshots
non-empty output.
- **`tests/main-repo-skew.test.js`**: Replace `@sinonjs/fake-timers`
with `mock.timers.enable()` from `node:test`.
- **`tests/README.md`**: Updated documentation to reflect `node --test`
and the new snapshot file.
- **`package.json`**: Remove `ava`, `@sinonjs/fake-timers`, and `execa`
from devDependencies. Update test script to `c8 --100 node --test
tests/index.js`.
- **`tests/index.js.snapshot`**: New text-based snapshot file replacing
binary `tests/snapshots/index.js.snap`.
- **`tests/snapshots/`**: Deleted.
All 22 test scenarios (66 subtests) pass with 100% code coverage.
Closes#344
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
(cherry picked from commit f863ba5554)
BREAKING CHANGE: Custom proxy handling has been removed. If you use HTTP_PROXY or HTTPS_PROXY, you must now also set NODE_USE_ENV_PROXY=1 on the action step.
Undici has added native support for proxy handling, so it is no longer necessary for us to have our own custom proxy handling.
Reverts #102 and resolves#134.
(cherry picked from commit cda91bf2b9)
This pull request fixes the handling of permissions inputs.
- Updated `getPermissionsFromInputs` in
`lib/get-permissions-from-inputs.js` to use hyphens
(`INPUT_PERMISSION-`) instead of underscores (`INPUT_PERMISSION_`) in
input keys, added a check to skip empty values, and clarified behavior
when no permissions are set.
- Added a `shouldRetry` function to retry requests when server errors
(HTTP status 500 or higher) occur in the `main` function in
`lib/main.js` to prevent unnecessary retries.
- Updated test cases in `tests/main-token-permissions-set.test.js` to
match the new input key format with hyphens.
- Added a default empty string for unset inputs (e.g.,
`INPUT_PERMISSION-ADMINISTRATION`) in `tests/main.js` to simulate the
behavior of the Actions runner.
- Updated snapshots in `tests/snapshots/index.js.md` to reflect the
updated hyphenated input keys in permissions.
---------
Co-authored-by: Gregor Martynus <39992+gr2m@users.noreply.github.com>
This PR switches from evaluating values passed to `skip-token-revoke` as
true if they are truthy in JavaScript, to using `getBooleanInput`. This
change ensures that only proper YAML boolean values are recognized,
preventing unintended evaluations to true.
- The definition of `getBooleanInput` is here: definition of
`core#getBooealnInput` is here:
https://github.com/actions/toolkit/blob/930c89072712a3aac52d74b23338f00bb0cfcb24/packages/core/src/core.ts#L188-L208
The documentation states, `"If truthy, the token will not be revoked
when the current job is complete"`, so this change could be considered a
breaking change. This means that if there are users who rely on `truthy`
and expect values like whitespace or `"false"` to be evaluated as true
(though this is likely rare), it would be a breaking change.
- `Boolean(" ")` and `Boolean("false")` are both evaluated as true.
Alternatively, it can simply be considered a fix. How to handle this is
up to the maintainer.
Resolves https://github.com/actions/create-github-app-token/issues/216
BREAKING CHANGE: Removed deprecated inputs (`app_id`, `private_key`, `skip_token_revoke`) and made `app-id` and `private-key` required in the action configuration.
- Load `app-permissions` from schema exported by `@octokit/openapi`
- Update documentation in README.md
- Implement the `permissions_*` inputs in the action code
---------
Co-authored-by: Parker Brown <17183625+parkerbxyz@users.noreply.github.com>
Combines the two installation requests (org and user) into one because
`/org/{org}` can also be accessed at `/users/{org}`.
---------
Co-authored-by: Gregor Martynus <39992+gr2m@users.noreply.github.com>
Resolves https://github.com/actions/create-github-app-token/issues/106
- Fixes the parsing to cope with whitespace in the input string.
- Allows the input to be comma or newline-separated. (I've done this for
all array-type inputs in my own actions, but I'm happy to remove this if
you only want to support comma-separated.)
- Added tests for parsing comma and newline-separated inputs.
This pull request fixes the file extension for two test files that were
incorrectly named. This caused them not to be tested. A new test has
been added to ensure all test files have the correct extension.
This also fixes a bug in some tests where `repositories` inputs included
the repository owner. The owner has been removed from these inputs and
the snapshots have been updated.
Closes#140
The pull request at #95 introduced changes to avoid revoking expired
tokens by saving the `expiresAt` value in the state. The change,
however, used `core.setOutput` instead of `core.setState` meaning the
value is not saved in the state but rather available in the output.
```javascript
if (!skipTokenRevoke) {
core.saveState("token", authentication.token);
core.setOutput("expiresAt", authentication.expiresAt);
}
```
This means that when we use the value downstream, it evaluates to an
empty string and the following code block is never run:
```javascript
const expiresAt = core.getState("expiresAt");
if (expiresAt && tokenExpiresIn(expiresAt) < 0) {
core.info("Token expired, skipping token revocation");
return;
}
```
This is a tiny PR to correct that typo.
It is convenient to use `https://api.github.com/users/$app_slug[bot]` to
obtain the corresponding account ID later.
Then build `Signed-off-by: $app_slug[bot]
<$id+$app_slug[bot]@users.noreply.github.com>`.
Currently, there is no Linux environment to build test snapshot files
Fixes#72
If an Actions job is long enough, more than an hour can pass between
creating and revoking the App token in the post-job clean up step. Since
the token itself is used to authenticate with the revoke API, an expired
token will fail to be revoked.
This PR saves the token expiration in the actions state and uses that in
the post step to determine if the token can be revoked. I've also added
error handling to the revoke token API call, as it's unlikely that users
would want their job to fail if the token can't be revoked.
GitHub's macOS runners for the past while have had some bad clock drift
which sometimes prevents this action from working with the error:
```console
'Issued at' claim ('iat') must be an Integer representing the time that the assertion was issued
```
`@octokit/auth-app` already has logic to handle this so we can defer to
that code.
Fixes#57
This PR implements the 3-step plan proposed by @gr2m in
https://github.com/actions/create-github-app-token/issues/57#issuecomment-1751272252:
> 1. Support both input types
> 2. Log a deprecation warning for the old notation
> 3. Add a test for deprecations
Although this PR supports both input formats simultaneously, I opted
_not_ to document the old format in the updated README. That’s a
decision I’m happy to revisit, if y’all would prefer to have
documentation for both the old and new formats.
Part of https://github.com/actions/create-github-app-token/issues/43
This PR adds tests for
[`main.js`](https://github.com/actions/create-github-app-token/blob/main/lib/main.js),
similar to [the tests that already exist for
`post.js`](https://github.com/actions/create-github-app-token/tree/main/tests).
Specifically, it tests that:
- `main` exits with an error when `GITHUB_REPOSITORY` is missing.
- `main` exits with an error when `GITHUB_REPOSITORY_OWNER` is missing.
- `main` successfully obtains a token when…
- …the `owner` and `repositories` inputs are set (and the latter is a
single repo).
- …the `owner` and `repositories` inputs are set (and the latter is a
list of repos).
- …the `owner` input is set (to an org), but the `repositories` input
isn’t set.
- …the `owner` input is set (to a user), but the `repositories` input
isn’t set.
- …the `owner` input is not set, but the `repositories` input is set.
- …neither the `owner` nor `repositories` input is set.
❧
Architecturally, in order to keep individual tests concise, this PR adds
`tests/main.js`, which:
- sets commonly-used inputs, environment variables, and mocks, then
- calls a callback function that can edit the variables and add
additional mocks, then
- runs `main.js` itself.
The `tests/main-token-get-*.test.js` test files run `tests/main.js` with
various scenario-specific callback functions.
Fixes https://github.com/actions/create-github-app-token/issues/55
Currently, `actions/create-github-app-token` always/unconditionally
revokes the installation access token in a `post` step, at the
completion of the current job. This prevents tokens from being used in
other jobs.
This PR makes this behavior configurable:
- When the `skip-token-revoke` input is not specified (i.e. by default),
the token is revoked in a `post` step (i.e. the current behavior).
- When the `skip-token-revoke` input is set to a truthy value (e.g.
`"true"`[^1]), the token is not revoked in a `post` step.
This PR adds a test for the `skip-token-revoke: "true"` case.
This is configurable in other app token actions, e.g.
[tibdex/github-app-token](https://github.com/tibdex/github-app-token/blob/3eb77c7243b85c65e84acfa93fdbac02fb6bd532/README.md?plain=1#L46-L47)
and
[wow-actions/use-app-token](https://github.com/wow-actions/use-app-token/blob/cd772994fc762f99cf291f308797341327a49b0c/README.md?plain=1#L132).
[^1]: Note that `"false"` is also truthy: `Boolean("false")` is `true`.
If we think that’ll potentially confuse folks, I can require
`skip-token-revoke` to be set explicitly to `"true"`.
dependabot[bot]