Repository navigation
ci: fix Playwright shard a (stop loading the case-mangled SDK dump) - #2129
Merged
Merged
Conversation
Shard a dropped 420_SDK after DB configuration and loaded cypress/e2e/plugins/items-planning-pn/a/420_sdk.sql, a 2023 export from a case-insensitive server with every table name lowercased (`__efmigrationshistory`, `caseversions`, ...). On the Linux MariaDB used in CI, table names are case-sensitive, so EF Core found no `__EFMigrationsHistory`, re-ran the SDK migrations from InitialCreate and failed with "Table 'notifications' already exists". Core start then failed on every request, /api/account/user-settings returned 500, the frontend never stored the user's claims, and #newEFormBtn (gated on eforms_create) never rendered, so login timed out. The only spec in shard a (plugin row check + activation) uses nothing from the dump. Shard a now keeps the SDK database that DB configuration created, like b and c. The rabbitmq host (which the dump used to set) is set for every shard, and one step sets the plugin status (1 for a, whose spec activates it; 2 for b and c) and restarts the container. The unreferenced dump is deleted, and shard a loses continue-on-error so a regression fails the run again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017kbiaVNigNkVARtq94xkDa
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
No unresolved issues were identified.
Review effort: Lite
Findings: None
What changed in this PR
Fixes Playwright shard a by removing an incompatible SQL dump and standardizing CI setup.
Changes:
- Removes the obsolete case-mangled SDK dump.
- Configures RabbitMQ and plugin status across shards.
- Makes shard
afailures block CI.
| File | Description |
|---|---|
eform-client/cypress/e2e/plugins/items-planning-pn/a/420_sdk.sql |
Removes the obsolete database dump. |
.github/workflows/dotnet-core-pr.yml |
Updates Playwright shard setup and error handling. |
.github/workflows/dotnet-core-master.yml |
Applies equivalent CI corrections on master. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Member
Author
|
Copilot review considered: no findings. All CI checks are green, including shard |
This was referenced Sep 27, 2026
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.
Closes #2128
Root cause
Playwright shard
ahas been red on every run since it was added (April 2026), not only recently. The same step also kept the old Cypresstest (a)job behindcontinue-on-error.After DB configuration, shard
adropped420_SDKand loadedeform-client/cypress/e2e/plugins/items-planning-pn/a/420_sdk.sql. That file is a 2023 Navicat export from a case-insensitive server, so every table name is lowercased:__efmigrationshistory,caseversions,settingsand so on. The CI MariaDB runs on Linux, where table names are case-sensitive. The failure then went like this:__EFMigrationsHistory, does not find it, and re-runs the SDK migrations fromInitialCreate. That stops withTable 'notifications' already exists, and later requests hitTable 'case_versions' already exists. The result isCore.StartSqlOnly failed.GET /api/account/user-settingsreturns 500. The trace shows 15+ of them, while/api/auth/claimsreturns 200 witheforms_create: True.zip(getUserSettings(), obtainUserClaims()), so the 500 means the claims never reach the store.#newEFormBtnis*ngIf="selectCurrentUserClaimsEformsCreate$ | async", so it never renders. The screenshot shows the logged-in "Mine eForms" page with no create buttons and empty menu entries.LoginPage.login()waits for that button until the test times out.Fix
ano longer loads the dump. Its only spec (a/items-planning-settings.spec.ts: plugin row check, then activation) uses none of the dump's data. It keeps the SDK database that DB configuration creates, the same as shardsbandc.a, whose spec activates the plugin; 2 forb/c) and restarts the container.continue-on-erroris removed for sharda, so a regression turns the run red again.dotnet-core-master.ymlgets the same change.No spec, assertion or wait changed. The long wait comes from
LoginPage.login(), which lives in eform-angular-frontend and is out of scope for this repo.🤖 Generated with Claude Code
https://claude.ai/code/session_017kbiaVNigNkVARtq94xkDa