TEMP: CI tests - #1465
Closed
lordrip wants to merge 10 commits into
Closed
Conversation
lordrip
marked this pull request as draft
August 10, 2026 15:25
Contributor
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
lordrip
force-pushed
the
fix/extester-update
branch
from
August 10, 2026 18:57
7736ca7 to
ed2cc36
Compare
The recommendation toasts are shown once per session by RecommendationCore, on a 6s timer after activation, so no test can synchronise with them -- extension.test.ts only saw them by happening to run at the right moment. Its lookups also passed an async predicate to Array.prototype.find, which never awaits, so they always matched the first notification: they dismissed unrelated toasts and left the recommendations stacked over the canvas for later tests. Suppress them suite-wide with extensions.ignoreRecommendations, close the drift in vscode-settings-minikube.json, and cover showRecommendedExtensions() with a unit test instead. The same find() defect is fixed in MavenDependencyUpdate, where the test does trigger the notification it looks for. That unit test is the first to import ExtensionContextHandler, which type-checks it under strict for the first time. openApiProvider and filePattern were only used inside the method that assigned them and become locals; testsProvider and deploymentsProvider are read across methods, so they take definite-assignment assertions as fileWatcher already did. Also ignores .bob-runs/, the run logs written by AI agent tooling. fix: KaotoIO#1467 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cz69Q95eYRiJ9oj8hBSKf5
resetUserSettings edited the file as text. ExTester writes settings.json minified onto a single line, which turned two latent defects into reliable corruption. The key regex was greedy with nothing to stop it: "." does not match a newline, but there are no newlines, so `"kaoto.nodeLabel.*` matched from the key to end of file and took every following setting and the closing brace with it. The dots in the id were unescaped too, so `"kaoto.catalog.url` also matched an unrelated key such as "kaotoXcatalogYurl". The follow-up replace then stripped the last comma unconditionally -- including when the first replace matched nothing, the common case when the setting was never written. Once the file is invalid, VS Code reports "Unable to write into user settings" and every later settings write silently fails, while setUserSettingsDirectly and readUserSetting throw on the same file. One comma was lost per call, so the damage accumulated across a run. Parse, delete the key, re-serialize instead. A missing key is then a no-op, a "." is literal, and the output matches setUserSettingsDirectly, which already writes JSON.stringify(settings, null, 4). fix: KaotoIO#1474 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cz69Q95eYRiJ9oj8hBSKf5
lordrip
force-pushed
the
fix/extester-update
branch
from
August 10, 2026 20:26
ed2cc36 to
8d1534f
Compare
ExTester's built-in `WebView.iframe` locator matches zero elements on VS Code 1.132.0, so `switchToFrame()` takes its `if (!view) return;` branch and silently does not switch. The driver stays in the workbench DOM and every webview query afterwards fails naming a perfectly valid Kaoto selector -- which is why this looked like a `.pf-v6-c-tabs__list` PatternFly locator mismatch rather than a frame resolution problem. The shipped locator is //div[not(@data-parent-flow-to-element-id)]/iframe[@Class='webview ready'] but VS Code renders the editor webview container with `data-parent-flow-to-element-id="webview-editor-element-<uuid>"`, and XPath `not(@attr)` tests attribute existence rather than its value, so every editor webview is excluded. Override it through the existing `customPageObjects` contribution with a CSS selector that does not predicate on that attribute. Note that accepting an empty attribute value is not sufficient: the value is non-empty once the webview is attached to its editor. Also harden `switchToKaotoFrame()`: verify that `#envelope-app`, the Kaoto webview root, is reachable after switching, and retry otherwise. That covers both a silent no-op and a switch into a foreign webview -- such as the "What's New" panel, which opens with `ViewColumn.Active` and can win ExTester's rect-based frame selection when two webviews share an editor group. Either way the suite now reports an honest failure instead of a misleading selector error. The open-file wait is relaxed from "tab is active" to "tab exists" for the same reason; making the Kaoto editor active is now `switchToKaotoFrame()`'s job, where it can be retried and verified. Part of KaotoIO#1469 Upstream: redhat-developer/vscode-extension-tester#2450 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cz69Q95eYRiJ9oj8hBSKf5
On Windows a single undismissed dialog fails every later test. All 24 `ElementClickInterceptedError` failures in the CI run name the same element -- `<div class="monaco-dialog-modal-block dimmed">`, VS Code's modal backdrop -- and the screenshot artifact shows the dialog itself: "Do you want to save the changes you made to settings.json?". The backdrop covers the window and swallows every click, so the reported failure names whatever element that test happened to click and looks unrelated to the real cause. The 5 "Extension 'Kaoto' was not activated within 150000ms" timeouts are the same bug rather than a separate one: `waitForExtensionActivation` falls back to `extensionIsActivated`, which has to click the Activity Bar. macOS shows zero interceptions, which is why this reads as Windows-specific. It is raised by the settings suites' cleanup: `resetUserSettings()` rewrites settings.json on disk while VS Code still has it open, and the following `View: Close Editor` prompts to save. Neither of those `after` hooks handled a dialog, so it stayed up for the remaining ~20 minutes. Add `dismissBlockingModal()`, which no-ops unless the backdrop is present and is safe to call unconditionally, and use it in both hooks. It falls back to 'Cancel' rather than to the opposite answer, since telling a caller that asked to save "Don't Save" would silently discard the change the test depends on. `closeEditor()` now decides the same way -- look for the dialog after closing -- instead of pre-probing with `new TextEditor().isDirty()`. The editor being closed is not always a text editor; the Settings UI is the common case here, so the old check could report "not dirty" and leave the prompt on screen. This removes the cascade, not the trigger: the settings suites still fail first at `checkTopologyLoaded` because the Kaoto webview does not render (KaotoIO#1468). Verified from the CI logs and screenshot artifacts; it could not be reproduced locally, where the webview does not render and the command palette is not interactable. Part of KaotoIO#1471 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cz69Q95eYRiJ9oj8hBSKf5
…n CI Do not merge. This pins the IT suite to an older VS Code purely to prove the root cause of KaotoIO#1468 on CI; pinning is not an acceptable long-term fix. Chromium 148 duplicates every 256 KiB chunk of a webview resource while a chromedriver/DevTools session is attached. The Kaoto webview bundle (10,440,390 bytes) arrives at ~20.9 MB as chunk0 chunk0 chunk1 chunk1 ..., which splits a `const` from its initializer. The script tag then throws `Uncaught SyntaxError: Missing initializer in const declaration`, the React app never mounts, `#envelope-app` stays empty and `checkTopologyLoaded` fails with "Kaoto topology was not loaded properly". Measured boundary, one run each: VS Code 1.120.0, 1.122.0 -> Chromium 142 -> bundle intact, topology renders VS Code 1.123.0 .. 1.132.0 -> Chromium 148 -> doubled, blank canvas The corruption is not size-dependent: a 1,066-byte resource also doubles (ratio exactly 2.0), so splitting the bundle is not a workaround. Launching the same VS Code by hand with all 24 of chromedriver's own flags, but with no driver attached, renders correctly - the driver attachment is the only variable. Verified locally on 1.122.0: BasicFlow 7/7, SwitchBetweenTabs 4/4, PropertyPanelLoading 1/1, ContextualMenuOpen 2/2 - all previously failing 100% on this machine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cz69Q95eYRiJ9oj8hBSKf5
|
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.
This PR is meant to incorporate fixes for CI on a branch that I can control. Once the fixes are found, these commits will be pushed to the original PR #1464