ci(release-please): pass the Client ID as client-id, not the deprecated app-id - #26
Merged
Merged
Conversation
…ed app-id APP_CLIENT_ID holds a Client ID, so it belongs in create-github-app-token's `client-id` input. `app-id` still accepts one, but the action now warns on it at runtime, and because this workflow is reusable that warning is emitted on every release across the org. actionlint bundles a snapshot of each action's inputs and its copy of create-github-app-token predates the rename, so it fails on `client-id` and simultaneously demands the `app-id` it replaced. v1.7.12 is the newest release and still carries the old set, so no linter bump resolves this. Suppress those two messages in .github/actionlint.yaml instead; the previous comment here said to wait for actionlint, but it has been a year and the warning fires org-wide in the meantime. Scoped to the two messages on this one file. php-tests.yml and php-composer-script.yml keep `app-id` deliberately: their credential is a caller-supplied `app-id` secret rather than a Client ID, and they stay covered by the normal rules. Both scope limits verified against 1.7.12 by injection: `client-id` in php-tests.yml still fails, and a private-key typo inside the suppressed file still fails. Callers are unaffected. The input rename carries the same credential to the same action, so no repo needs to change how it calls this workflow. Assisted-by: Claude Code
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-on to openCoreEMR/toolbox#32, which made the same change there.
APP_CLIENT_IDholds a Client ID, so it belongs increate-github-app-token'sclient-idinput.app-idstill accepts one but the action now warns at runtime, and because this workflow is reusable, that warning fires on every release across the org.Why this needs a lint suppression
actionlint bundles a snapshot of each action's inputs and its copy of
create-github-app-tokenpredates the rename, soclient-idproduces two hard errors. v1.7.12 is the newest actionlint release and still carries the old set, so there is no linter bump that fixes it.The existing comment in this file said to stay on
app-id"until actionlint catches up". That was written a year ago; meanwhile the warning fires org-wide on every release..github/actionlint.yamlsuppresses the two messages instead.Scope is narrow, and verified
php-tests.ymlandphp-composer-script.ymlkeepapp-iddeliberately — their credential is a caller-suppliedapp-idsecret, not a Client ID, so the rename does not apply to them. They stay covered by the normal rules.Both limits checked by injecting the case and re-running actionlint 1.7.12:
client-idinjected intophp-tests.yml(not in the config)private-keymistyped inside the suppressed fileCallers
Unaffected. The rename passes the same credential to the same action, so no repo needs to change how it calls this workflow.
Delete
.github/actionlint.yamlonce actionlint ships the renamed input; both it and the workflow say so.