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>
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>
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)
Bumps
[@actions/core](https://github.com/actions/toolkit/tree/HEAD/packages/core)
from 1.11.1 to 3.0.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/actions/toolkit/blob/main/packages/core/RELEASES.md"><code>@actions/core</code>'s
changelog</a>.</em></p>
<blockquote>
<h2>3.0.0</h2>
<ul>
<li><strong>Breaking change</strong>: Package is now ESM-only
<ul>
<li>CommonJS consumers must use dynamic <code>import()</code> instead of
<code>require()</code></li>
</ul>
</li>
</ul>
<h2>2.0.3</h2>
<ul>
<li>Bump <code>@actions/http-client</code> to <code>3.0.2</code></li>
</ul>
<h2>2.0.1</h2>
<ul>
<li>Bump <code>@actions/exec</code> from 1.1.1 to 2.0.0 <a
href="https://redirect.github.com/actions/toolkit/pull/2199">#2199</a></li>
</ul>
<h2>2.0.0</h2>
<ul>
<li>Add support for Node 24 <a
href="https://redirect.github.com/actions/toolkit/pull/2110">#2110</a></li>
<li>Bump <code>@actions/http-client</code> from 2.0.1 to 3.0.0</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/actions/toolkit/commits/HEAD/packages/core">compare
view</a></li>
</ul>
</details>
<details>
<summary>Maintainer changes</summary>
<p>This version was pushed to npm by [GitHub Actions](<a
href="https://www.npmjs.com/~GitHub">https://www.npmjs.com/~GitHub</a>
Actions), a new releaser for <code>@actions/core</code> since your
current version.</p>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
---------
Co-authored-by: Parker Brown <17183625+parkerbxyz@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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.
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.
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"`.
Follow up to #36. I just wanted to do some refactoring but turns out I
missed to pass the custom `request` instance to `createAppAuth`. It will
fallback to the default `request` which does not respect
`GITHUB_API_URL`
Check before trying to revoke the token, in case the token generation
failed. Otherwise the post step will throw an error.
---------
Co-authored-by: Gregor Martynus <39992+gr2m@users.noreply.github.com>
The runner will automatically mask GitHub token formats it recognizes,
but sometimes a new pattern rolls out before the runner is updated to
recognize it.
Stefan