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.
Omochice