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.
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
- 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>
### Fix syntax error in GitHub Actions example in README
This PR fixes a syntax error in the "Create a git committer string for
an app installation" example in the README file.
#### What was wrong?
The example contained an incorrect space in the variable syntax:
```yaml
${ {steps.committer.outputs.string }}
```
This caused the example to fail, as GitHub Actions does not allow spaces
in variable interpolation.
#### What was fixed?
The syntax was corrected to:
```yaml
${{ steps.committer.outputs.string }}
```
This fix ensures that users can copy and use the example without
encountering any errors.
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.
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
Using those fields that have an underscore (instead of a hyphen) cause
the following warnings if used:
```
Warning: Input 'app_id' has been deprecated with message: 'app_id' is deprecated and will be removed in a future version. Use 'app-id' instead.
Warning: Input 'private_key' has been deprecated with message: 'private_key' is deprecated and will be removed in a future version. Use 'private-key' instead.
```
So this PR just drops the last use of `app_id` and `private_key` from
the README in favor of `app-id` and `private-key`.
# General Improvements
> This is a classic @GrantBirki drive-by PR 🚗
This pull request does the following:
- Lightly updates and formats a few existing Actions workflows
- Adds a new `package-check` workflow to validate the contents of the
`dist/` directory have been properly built
- Uses a `.node-version` file so that local development and Actions
remain on the same pinned version of node
- Adds status badges to the readme for visual effect ⭐🎨
Adds an example workflow to the README that shows how a matrix strategy can be used to create tokens for multiple user or organization accounts. Resolves#45.
This is a quick follow-up to #59. I was mid-review when it merged and
noticed one instance of `skip_token_revoke` in the README that didn't
get changed to `skip-token-revoke`. The PR merged just before I pushed a
commit to fix it.
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"`.
With #13, this action is explicitly masking the token so we don't need to mention that we're relying on a specific format of GitHub tokens being masked by the runner.
- Update title
- Remove blockquote formatting from description to improve accessibility
- Capitalize "app" in "GitHub App" for consistency
- Add missing periods in unordered list
- Use new highlight syntax for note
Stefan