ci(release): use short-lived GitHub App token instead of long-lived PAT#13604
Merged
Conversation
ilhan007
added a commit
that referenced
this pull request
Jun 1, 2026
The experimental flow only publishes to npm — it does not push commits, tags, or anything else back to GitHub. The long-lived PAT was therefore unnecessary in this job; the auto-issued GITHUB_TOKEN suffices. Also downgrades 'contents' permission from 'write' to 'read' to match what the job actually needs (checkout only). Other release jobs (stable, rc, hotfix, v1) still push to protected branches and continue to use UI5_WEBCOMP_BOT_GH_TOKEN; they will be migrated separately (see #13604).
ilhan007
added a commit
that referenced
this pull request
Jun 2, 2026
…ix from secret names Addresses review feedback on #13604: - pin actions/create-github-app-token to v3.2.0 commit SHA per GitHub third-party action security guidance (tags can be moved, SHAs cannot) - v3 is safe for us: breaking changes are Node 24 (we use ubuntu-latest hosted runners which support it) and removed custom proxy handling (we do not use proxies) - rename RELEASE_BOT_APP_ID / RELEASE_BOT_APP_PRIVATE_KEY to RELEASE_APP_ID / RELEASE_APP_PRIVATE_KEY to match repo secret names
Replace every `secrets.UI5_WEBCOMP_BOT_GH_TOKEN` usage in the release workflow with a per-run installation token generated by `actions/create-github-app-token@v2`. App tokens are valid for ~1 hour and disappear when the run ends, drastically reducing the blast radius compared to a long-lived PAT. Aligns release.yaml with OSPO Guideline #4 ("Replace long-lived secrets with OIDC"). The same PAT is still consumed by deploy-preview.yaml, reset-preview-deploy.yaml, reset-gh-pages.yaml and issue-monthly-report.yaml; those workflows are intentionally out of scope and will be migrated in follow-up PRs. Requires (one-time, before merge): - Register a GitHub App with Contents/Issues/Pull-requests: write - Install it on SAP/ui5-webcomponents - Add it to the branch-protection bypass list for release branches - Add repo secrets RELEASE_BOT_APP_ID and RELEASE_BOT_APP_PRIVATE_KEY The npm publish flow already uses OIDC (id-token: write, no NPM_TOKEN); no changes there. UI5_WEBCOMP_BOT_NAME / _EMAIL are kept as-is — they are git identity strings, not credentials.
…ix from secret names Addresses review feedback on #13604: - pin actions/create-github-app-token to v3.2.0 commit SHA per GitHub third-party action security guidance (tags can be moved, SHAs cannot) - v3 is safe for us: breaking changes are Node 24 (we use ubuntu-latest hosted runners which support it) and removed custom proxy handling (we do not use proxies) - rename RELEASE_BOT_APP_ID / RELEASE_BOT_APP_PRIVATE_KEY to RELEASE_APP_ID / RELEASE_APP_PRIVATE_KEY to match repo secret names
Resolves the merge conflict between this PR and main introduced by 49bade4 ("swap PAT for GITHUB_TOKEN in experimental-release job"). experimental-release does not push tags or branches, does not create a GitHub release, and does not need elevated privileges — GITHUB_TOKEN is sufficient. Removes the now-unused 'Generate App Token' step from this job and reverts contents permission from write back to read. App tokens remain in stable/rc/hotfix/v1 jobs where they're needed for tag pushes against branch-protected refs.
actions/checkout@v4 already defaults to github.token, and lerna version --no-push + lerna publish in this job do not need GH_TOKEN in env. Addresses review feedback on #13571.
0bd5242 to
8773e48
Compare
ilhan007
added a commit
that referenced
this pull request
Jun 3, 2026
Replace secrets.UI5_WEBCOMP_BOT_GH_TOKEN with a per-run installation token from actions/create-github-app-token@v3.2.0 (pinned by SHA) in: - deploy-preview.yaml - reset-preview-deploy.yaml - reset-gh-pages.yaml - issue-monthly-report.yaml Completes the OSPO Hardening Control #4 ("Replace long-lived secrets with OIDC") migration started in #13604. release.yaml was migrated there; this PR covers the four remaining workflows that were called out as out-of-scope at the time. Once merged and one run of each workflow is verified green, the UI5_WEBCOMP_BOT_GH_TOKEN secret can be deleted and the underlying PAT revoked. The UI5_WEBCOMP_BOT_NAME and UI5_WEBCOMP_BOT_EMAIL secrets are kept — they are git identity strings, not credentials.
Collaborator
Author
|
@dellagustin-sap after the token generation has been tested and worked, I replaced all the usages of the classic long-lived token with this PR The ui5-webcomponents-bot is no longer an admin. |
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.
Background
Aligns release.yaml with OSPO Guideline # 4.Replace long-lived secrets with OIDC
Change
Replace every
secrets.UI5_WEBCOMP_BOT_GH_TOKENusage in the release workflow with a per-run installation token generated byactions/create-github-app-token@v3. App tokens are valid for ~1 hour and disappear when the run ends, drastically reducing the blast radius compared to a long-lived PAT.Prerequisite (one-time, before merge ):
by OSPO team
by us