fix(website-ci): mint a real Keycloak token from the password before cloud builds#5249
Merged
Conversation
…cloud builds The website docs JS cloud builds hang in CI at "Waiting for login...". Root cause: CN1_TOKEN holds the account *password*, but build.sh fed it to `cn1:set-user-token`, which writes it verbatim into the Java prefs "token" slot. The build then sends it as `Authorization: Bearer <password>` to the cloud server, which parses it as a JWT, 401s, and falls back to an interactive browser login no CI runner can answer. A password is not a bearer token. Exchange it for a short-lived Keycloak access token via an OAuth2 direct access grant (public cn1cloudapp client, which has Direct Access Grants enabled) and seed THAT instead. The token is minted per-build (set_cn1_user_token runs before each JS build), so it is fresh and won't expire mid-build for normal build durations. No CodeNameOneBuildClient.jar change required — the existing build flow works once the prefs "token" is an actual token. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Cloudflare Preview
|
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
2 participants
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.
Symptom
The "Build Hugo Website" workflow hangs the JS cloud builds at
Waiting for login...—CodeNameOneBuildTasktries to open a browser no CI runner can answer.Root cause
CN1_TOKENholds the account password, not a build token.scripts/website/build.shfed it straight tocn1:set-user-token(and theSetCn1Prefsfallback), which writes it verbatim into the Java prefstokenslot. The build then sendsAuthorization: Bearer <password>to the cloud server; the resource server tries to parse a password as a JWT, returns 401, and the client falls back to the interactive browser login. A password can never be a bearer token, so it fails every time (the old App Engine username/password fallback that used to mask this is gone).Fix
In
set_cn1_user_token, exchange the password for a short-lived Keycloak access token (OAuth2 direct access grant on the publiccn1cloudappclient — Direct Access Grants is enabled) and seed that as the prefs token:Minted per-build (this runs before each JS build), so it's fresh — no mid-build expiry for normal durations. No
CodeNameOneBuildClient.jarchange needed — the existing flow works once the prefstokenis an actual token (alternative to the JAR-swap branch).Triggers the build
Touches
scripts/website/**, which is in thewebsite-docs.ymlpull_requestpath filter — so this PR runs the website build and exercises the fix end-to-end.Note
If a cloud build ever exceeds the realm's access-token lifespan, bump Access Token Lifespan for the
Realmrealm in Keycloak.CN1_TOKENsecret stays as the password (no value change).🤖 Generated with Claude Code