Repository navigation
fix(tests): Add keycloak warmup step for CLI tests - #7555
maverbiest wants to merge 1 commit into
Conversation
|
Claude finished @maverbiest's task in 29s —— View job Code review
This is a small, focused fix for a real race condition, and I found no blocking issues. The comment in the setup file explains why the warmup exists and why it uses the plain Playwright Config filtering: The warmup project runs in the Inline comments (both optional):
Docs: The Testing: Please record in the PR checklist which manual check you ran, for example several CLI runs against a freshly deployed instance with no failures. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| name: keycloakWarmupName, | ||
| use: { ...devices['Desktop Chrome'] }, | ||
| testMatch: /keycloak-warmup\.setup\.ts/, | ||
| }, |
There was a problem hiding this comment.
Browser suites can hit the same race: chromium-without-dep and firefox-without-dep start many parallel tests that load Keycloak pages on a fresh pod. Consider adding dependencies: [keycloakWarmupName] to those projects too, and keeping keycloakWarmupName in the TEST_SUITE === 'browser' filter. Leaving it CLI-only is fine if the flakiness has only shown up there, but it's cheap to add.
There was a problem hiding this comment.
These already have their own readonlySetupName, IIUC that should already ensure the keycloak cache is populated
There was a problem hiding this comment.
Ah but not all browser tests are run with-dep! So sometimes they run into this failure mode as well, will add the warmup to those as well
| await page.goto('/'); | ||
| await page.getByRole('link', { name: 'Login' }).click(); | ||
| await page.waitForLoadState('networkidle'); | ||
| await page.getByRole('link', { name: 'Register' }).click(); | ||
| await page.waitForLoadState('networkidle'); |
There was a problem hiding this comment.
Small robustness point: if this step fails (for example, the Login link is renamed or the page loads slowly), Playwright skips every dependent CLI test. Those tests would then show as skipped rather than failed, which is easy to miss. If the warmup is meant to be best-effort, consider wrapping the body in try/catch and logging the error. Otherwise it's fine as is, since a failure here usually means the real tests would fail too.
Also, auth.page.ts already does the same Login → Register navigation. The duplication is OK because this test intentionally avoids the console-warnings fixture.
|
Closing as duplicate: #7429 |
1 participant
I noticed integration tests were sometimes failing the first time they were run for a PR because of a failure to load resources or stylesheets, e.g.:
Rerunning the job fixed it each time, it turns out it's due to keycloak gzipping and caching resources when they're requested for the first time. When several requests for theme files arrive at once on a freshly started pod, some of them fail with a 404.
This PR adds a warmup step to the CLI integration tests that loads keycloak resources so they are gzipped and cached in advance of the actual tests running.
PR Checklist
🚀 Preview: Add
previewlabel to enable