Fix stale metadata for actions/create-github-app-token#652
Fix stale metadata for actions/create-github-app-token#652anthonymonori wants to merge 4 commits into
actions/create-github-app-token#652Conversation
Update actions/create-github-app-token@v3 so client-id is accepted and app-id is treated as deprecated instead of required. Add a fixture covering the moving v3 tag with client-id.
Add an explicit actions/[email protected] entry to preserve the old input shape for workflows pinned to that exact version. Add a fixture covering the exact ref with app-id.
Add [email protected] to the popular actions registry and regenerate popular_actions.go so the v3 entry matches the current upstream metadata while preserving the exact v3.0.0 shape.
I think the latter way is adopted in this repo. BTW, input updates in But recently it failed because new releases of popular actions were detected but they were missing from the https://github.com/rhysd/actionlint/actions/runs/24594466017/job/71921705206#step:4:207 |
Remove the exact v3.0.0 entry and fixture so this stays limited to the current actions/create-github-app-token@v3 metadata fix.
|
Thanks @muzimuzhi for pointing that out. Was looking around how to address that issue as I ran into it locally, but I didn't see that we have a way to auto-update metadata. I guess if that workflow would be fixed, we would get a PR that patches this change for v3 anyway? In that case, I'm happy to close this down and go that route. 🙏 In the meanwhile I also removed the regression case and reduced this PR to the minimal change in 778f197 |
intent(private-repo-app): integrate the standalone app.yml prototype into action.yml so users can pull private GitHub deps via this action's inputs decision(input-naming): named the inputs private-repo-app-* so the purpose (private repo access via a GitHub App) is obvious from the input list rejected(input-naming): bare app-* / owner / repositories from the prototype — too generic, no hint that they enable private repo access decision(rewrite-mechanism): GIT_CONFIG_COUNT / GIT_CONFIG_KEY_<n> / GIT_CONFIG_VALUE_<n> env vars to layer url.*.insteadOf on top of the existing global git config rejected(rewrite-mechanism): replacing GIT_CONFIG_GLOBAL with a temp gitconfig — drops the runner's existing global settings and hardcodes ~/.gitconfig while git also reads ~/.config/git/config decision(rewrite-scope): emit per-repository url.*.insteadOf entries so the token only attaches to repos that are in the App installation scope rejected(rewrite-scope): owner-wide rewrite — would catch other repos under the same owner and 404 because the installation token is scoped to specific repos constraint(poetry-git-client): Poetry's default dulwich client ignores GIT_CONFIG_* env vars; POETRY_SYSTEM_GIT_CLIENT / POETRY_EXPERIMENTAL_SYSTEM_GIT_CLIENT are forced so the rewrite applies constraint(cleanup-position): cleanup runs after pre-commit/prek (not right after Setup environment) so private hook repos can still be fetched while the rewrite is active constraint(cleanup-failure-mode): cleanup uses always() so the rewrite is dropped even when poetry install / uv sync fails, preventing the token-bearing env vars from leaking into later if: always() steps learned(actionlint-client-id): actionlint < rhysd/actionlint#652 does not yet recognize client-id on actions/create-github-app-token, hence the .github/actionlint.yaml ignore entries
@v3currently reflects the oldv3.0.0input shape, which causes false positives when workflows useclient-idand the current movingv3tag.Example output (before changes in this PR):
actions/[email protected] release notes
This updates the popular actions registry and regenerates
popular_actions.goso that:actions/create-github-app-token@v3matches the current upstreamv3metadataactions/[email protected]is kept as a separate exact entry for workflows pinned to that versionFixes #648
I've checked the CONTRIBUTIONS doc, ran linting, ran
go generate(there actually was some other unrelated changes foraws-actions/configure-aws-credentials@v6that i reverted since it's unrelated to this PR but just an FYI).Let me know if I missed anything! 🙏 Or if you would prefer if we don't add the 3.0.0 regression case and just change the 1 line that's matters.