@camunda/e2e-test-suite 0.0.1102 → 0.0.1104

package/dist/pages/8.10/ModelerCreatePage.js

@@ -1409,23 +1409,47 @@ class ModelerCreatePage {
         //   1. Connect cluster → "Configure environment" modal → select cluster → Save
         //   2. Deploy process → wait for success banner
         //   3. Configure test case
-        const setupDeployButton = this.page
-            .getByText('Deploy process')
-            .locator('..')
-            .getByRole('button', { name: 'Deploy' });
-        // Both attributes on this button have been renamed by camunda-hub, in
-        // separate commits: a90fd06 changed the label from "Configure scenario" to
-        // "Configure test case", and b3958a1649 (#27259, 2026-08-07) then changed
-        // the test id from `play-configuration-configure-scenario-button` to
-        // `configure-test-case-button`. Match current test id, then pre-rename test
-        // id, then either label, so a further rename of any single attribute cannot
-        // break the step.
+        // camunda-hub 8b42269 ("unify Setup environment / Configure test case
+        // panel, polish", #28226, 2026-09-04) replaced ConfigurationOverlay with
+        // TestConfigurationPanel, a Carbon Accordion. "Deploy process" is now only
+        // the accordion HEADER label and the Deploy button lives in the item's
+        // separate content wrapper, so scoping by getByText('Deploy process') ->
+        // '..' resolves to the header's own span and matches no button at all --
+        // isEnabled() then throws, the probe reads false forever and the settle
+        // wait below times out even though Deploy is on screen and enabled. The
+        // data-testid is unchanged between the old overlay and the new panel, so
+        // anchor on it instead.
+        const setupDeployButton = this.page.getByTestId('test-configuration-deploy-button');
+        // The same commit dropped the "Process has been successfully deployed."
+        // sentence in favour of a "Successfully deployed" badge. Match the badge's
+        // test id first, keep the old sentence for pre-8b42269 modeler builds.
+        //
+        // Probed by ATTACHMENT, never visibility: the badge renders only once the
+        // product reports the deploy succeeded, but the panel reacts to that same
+        // state by hiding the setup overlay, which collapses the "Deploy process"
+        // accordion item the badge lives in. So it is present-but-hidden within a
+        // frame of appearing, and a toBeVisible() wait on it can never pass.
+        const deploySuccessBadge = this.page
+            .getByTestId('deploy-success-badge')
+            .or(this.page.getByText('Process has been successfully deployed'))
+            .first();
+        const isDeployReported = async () => (await deploySuccessBadge.count()) > 0;
+        // Legacy-only button. camunda-hub renamed it twice (a90fd06 label
+        // "Configure scenario" -> "Configure test case"; b3958a1649 (#27259,
+        // 2026-08-07) test id `play-configuration-configure-scenario-button` ->
+        // `configure-test-case-button`) and then 8b42269 removed it outright: the
+        // accordion panel hides the setup overlay and opens step 3 by itself once
+        // the deploy step completes, so there is nothing left to click. Keep the
+        // locator for older modeler builds and drive it only when it is really
+        // there. Match test ids ONLY: the accessible name of the new accordion's
+        // step-3 heading button is also exactly "Configure test case" (its "3"
+        // marker is aria-hidden), so a `getByRole('button', {name: ...})` fallback
+        // silently binds to that heading instead. That made the deploy step look
+        // already-done (the heading is visible while disabled) and then spent the
+        // whole retry budget clicking a permanently disabled heading.
         const configureScenarioButton = this.page
             .getByTestId('configure-test-case-button')
             .or(this.page.getByTestId('play-configuration-configure-scenario-button'))
-            .or(this.page.getByRole('button', {
-            name: /^Configure (test case|scenario)$/,
-        }))
             .first();
         // Play settles into exactly ONE of three states, and which one is not
         // knowable up front, so race them instead of timing out on each in turn:
@@ -1480,10 +1504,14 @@ class ModelerCreatePage {
             // Deploy button and then waits forever for a "Connect cluster" button that
             // never renders (it has become "Change").
             //
-            // Wait until the panel settles into one of two stable states before
+            // Wait until the panel settles into one of three stable states before
             // deciding, then branch:
             //   - "Connect cluster" button visible → no cluster connected, connect one
             //   - Deploy button enabled            → a cluster is already connected
+            //   - deploy success badge visible     → re-entering an already deployed
+            //     process application, where the Deploy button is replaced by the
+            //     badge and "Connect cluster" by "Change", so neither of the first
+            //     two states is ever reached
             const connectClusterButton = this.page.getByRole('button', {
                 name: 'Connect cluster',
             });
@@ -1494,7 +1522,8 @@ class ModelerCreatePage {
                 const deployEnabled = await setupDeployButton
                     .isEnabled()
                     .catch(() => false);
-                (0, test_1.expect)(connectVisible || deployEnabled).toBe(true);
+                const deployDone = await isDeployReported();
+                (0, test_1.expect)(connectVisible || deployEnabled || deployDone).toBe(true);
             }).toPass({ timeout: 30000 });
             const needsClusterConnect = await connectClusterButton
                 .isVisible()
@@ -1536,24 +1565,34 @@ class ModelerCreatePage {
             // processApplicationId is defined, which it now is, so re-entering
             // Play on an already-deployed process application legitimately
             // has nothing to deploy and renders no Deploy button at all.
-            const alreadyDeployed = await configureScenarioButton
-                .isVisible({ timeout: 3000 })
-                .catch(() => false);
+            const alreadyDeployed = (await isDeployReported()) ||
+                (await configureScenarioButton
+                    .isVisible({ timeout: 3000 })
+                    .catch(() => false)) ||
+                (await configureTestPanel.isVisible().catch(() => false));
             if (!alreadyDeployed) {
                 // Step 2: deploy — wait for enabled; button stays disabled until the cluster
                 // connection is confirmed by the backend after the Save in step 1.
                 await (0, test_1.expect)(setupDeployButton).toBeEnabled({ timeout: 30000 });
                 await setupDeployButton.click({ timeout });
-                await (0, test_1.expect)(this.page.getByText('Process has been successfully deployed')).toBeVisible({ timeout: 90000 });
+                await (0, test_1.expect)(deploySuccessBadge).toBeAttached({ timeout: 90000 });
             }
-            // Step 3: leave the overlay, and confirm we actually left it. The
-            // button only calls hideConfigurationOverlay(); the overlay's own
-            // cluster-change effect can then fire resetDeployment and bring it
-            // straight back, and ConfigureTestPanel stays null while it is up.
-            // Assert the panel really rendered, and re-drive the click if the
-            // overlay returned.
+            // Step 3: reach the configure-test panel and confirm it really rendered.
+            // The accordion panel opens step 3 on its own once the deploy step
+            // completes (TestConfigurationPanel hides the setup overlay in an
+            // effect); only the legacy overlay needed the "Configure test case"
+            // click, and that click only called hideConfigurationOverlay(), so the
+            // overlay's cluster-change effect could fire resetDeployment and bring
+            // it straight back. Re-drive the button when it exists, but key the
+            // retry on the panel rather than on the overlay: the new panel keeps its
+            // "Setup environment" heading on screen alongside step 3, so an
+            // overlay-visible check is now permanently true and would loop on a
+            // button that no longer exists.
             await (0, test_1.expect)(async () => {
-                if (await configurationOverlay.isVisible()) {
+                const hasConfigureButton = await configureScenarioButton
+                    .isVisible()
+                    .catch(() => false);
+                if (hasConfigureButton) {
                     await configureScenarioButton.click({ timeout });
                 }
                 await (0, test_1.expect)(configureTestPanel).toBeVisible({ timeout: 15000 });

package/dist/pages/8.7/ModelerCreatePage.js

@@ -1226,20 +1226,39 @@ class ModelerCreatePage {
             .locator('..')
             .getByRole('button', { name: 'Deploy' }))
             .first();
-        // Both attributes on this button have been renamed by camunda-hub, in
-        // separate commits: a90fd06 changed the label from "Configure scenario" to
-        // "Configure test case", and b3958a1649 (#27259, 2026-08-07) then changed
-        // the test id from `play-configuration-configure-scenario-button` to
-        // `configure-test-case-button`. Match current test id, then pre-rename test
-        // id, then either label, so a further rename of any single attribute cannot
-        // break the step.
-        const configureScenarioButton = this.page
+        // Deploy completion signal. camunda-hub 8b4226983e (#28226, 2026-09-04)
+        // replaced the overlay's "Process has been successfully deployed." status
+        // text with a badge carrying `deploy-success-badge`; keep the old sentence
+        // as a fallback for modeler builds from before that commit.
+        const deploySuccessBadge = this.page
+            .getByTestId('deploy-success-badge')
+            .or(this.page.getByText('Process has been successfully deployed'))
+            .first();
+        // The same commit unified the setup overlay and the configure panel into
+        // one accordion ("Setup environment" card, TestConfigurationPanel), which
+        // deleted the `configure-test-case-button` primary button entirely: step 3
+        // is now an accordion heading that is `disabled` until the deploy step
+        // completes, and it opens on its own via a `hideConfigurationOverlay()`
+        // effect once it does. So this locator is only a *fallback* nudge for when
+        // the panel did not auto-open -- never the thing that advances the flow.
+        // It must therefore never be used as an "is the deploy done" probe: the
+        // heading is visible-but-disabled from the moment Play mounts, which is
+        // exactly what made the old `alreadyDeployed` probe skip the deploy step
+        // and then burn its whole budget clicking a permanently disabled button.
+        const configureStepHeading = this.page
             .getByTestId('configure-test-case-button')
             .or(this.page.getByTestId('play-configuration-configure-scenario-button'))
             .or(this.page.getByRole('button', {
             name: /^Configure (test case|scenario)$/,
         }))
             .first();
+        // Step 2 is an accordion item too, and its content (the Deploy button)
+        // only renders visibly while that item is expanded. It expands by itself
+        // once the cluster step completes, but a manual heading click is the
+        // recovery path if it did not.
+        const deployStepHeading = this.page.getByRole('button', {
+            name: 'Deploy process',
+        });
         // Play settles into exactly ONE of three states, and which one is not
         // knowable up front, so race them instead of timing out on each in turn:
         // the setup overlay, the legacy Continue button, or the configure-test
@@ -1261,8 +1280,11 @@ class ModelerCreatePage {
         // `test-studio-configuration-overlay` (confirmed in a failing run's trace
         // DOM, and already fixed the same way in pages/SM-8.10). Anchor on the
         // new data-test, keep the legacy attribute for older modeler builds, and
-        // fall back to the "Setup environment" panel title. This locator means
-        // "the setup panel is still on screen".
+        // fall back to the "Setup environment" panel title. Since 8b4226983e the
+        // data-test containers are gone and only the title matches, and the title
+        // stays on screen once the configure step opens -- so this locator now
+        // means "the setup panel exists", i.e. we are on the new flow. It is not a
+        // signal that setup is still pending; `configureTestPanel` is.
         const configurationOverlay = this.page
             .locator('[data-test="test-studio-configuration-overlay"]')
             .or(this.page.locator('[data-test="play-configuration-overlay"]'))
@@ -1320,30 +1342,81 @@ class ModelerCreatePage {
                     .getByRole('button', { name: 'Save' })
                     .click({ timeout });
             }
-            // Step 2: deploy, unless the overlay already opened with the
-            // deploy step complete. checkExistingDeployment only runs when
-            // processApplicationId is defined, which it now is, so re-entering
-            // Play on an already-deployed process application legitimately
-            // has nothing to deploy and renders no Deploy button at all.
-            const alreadyDeployed = await configureScenarioButton
-                .isVisible({ timeout: 3000 })
-                .catch(() => false);
-            if (!alreadyDeployed) {
-                // Step 2: deploy — wait for enabled; button stays disabled until the cluster
+            // Step 2: deploy, unless the setup panel already opened with the deploy
+            // step complete. checkExistingDeployment only runs when
+            // processApplicationId is defined, which it now is, so re-entering Play
+            // on an already-deployed process application legitimately has nothing to
+            // deploy and renders the success badge instead of a Deploy button.
+            //
+            // `deploy-success-badge` on its own is NOT a usable "is the deploy done"
+            // probe. DeployStepContent renders it inside the "Deploy process"
+            // accordion item, and TestConfigurationPanel collapses that item the
+            // instant the deploy finishes (`isDeployStepComplete` ->
+            // `hideConfigurationOverlay()` -> `isDeployOpen` false). Carbon keeps a
+            // collapsed accordion's content mounted, so the badge stays in the DOM
+            // but never becomes visible again -- which is exactly the nightly
+            // failure: the locator resolved to the badge on every poll and read
+            // "hidden" all 89 times. DeployStepIcon carries the same state in the
+            // accordion *heading*, which stays on screen while the item is
+            // collapsed, and the configure panel only opens once the deploy step
+            // completes, so treat any of the three as proof.
+            const deployCompleteIcon = this.page.locator('[aria-label="Deployment complete"]');
+            const isDeployComplete = async () => (await deployCompleteIcon.isVisible().catch(() => false)) ||
+                (await deploySuccessBadge.isVisible().catch(() => false)) ||
+                (await configureTestPanel.isVisible().catch(() => false));
+            if (!(await isDeployComplete())) {
+                // The Deploy button lives inside the "Deploy process" accordion item,
+                // which expands itself once the cluster step completes. Nudge the
+                // heading if it is still collapsed, otherwise the button is present
+                // but hidden and the click below would time out.
+                const deployButtonShown = await setupDeployButton
+                    .isVisible({ timeout: 30000 })
+                    .catch(() => false);
+                if (!deployButtonShown) {
+                    const canExpandDeployStep = await deployStepHeading
+                        .isEnabled({ timeout: 5000 })
+                        .catch(() => false);
+                    if (canExpandDeployStep) {
+                        await deployStepHeading.click({ timeout });
+                    }
+                }
+                // Wait for enabled; the button stays disabled until the cluster
                 // connection is confirmed by the backend after the Save in step 1.
                 await (0, test_1.expect)(setupDeployButton).toBeEnabled({ timeout: 60000 });
-                await setupDeployButton.click({ timeout });
-                await (0, test_1.expect)(this.page.getByText('Process has been successfully deployed')).toBeVisible({ timeout: 90000 });
+                // The click is retried against the completion probe rather than fired
+                // once, because the same collapse re-renders the accordion around the
+                // button: it detaches mid-click, which is the second nightly symptom
+                // ("element is not visible", 58 retries, in the click call log). A
+                // re-click can only happen while the deploy is provably still
+                // incomplete AND the button is enabled -- a deploy in flight disables
+                // it and a finished deploy replaces it with the badge, so this cannot
+                // double-deploy. If the deploy never completes the loop still fails.
+                await (0, test_1.expect)(async () => {
+                    if (await isDeployComplete()) {
+                        return;
+                    }
+                    const canClick = (await setupDeployButton.isVisible().catch(() => false)) &&
+                        (await setupDeployButton.isEnabled().catch(() => false));
+                    if (canClick) {
+                        await setupDeployButton.click({ timeout });
+                    }
+                    (0, test_1.expect)(await isDeployComplete()).toBe(true);
+                }).toPass({ timeout: 120000, intervals: [1000, 2000, 5000] });
             }
-            // Step 3: leave the overlay, and confirm we actually left it. The
-            // button only calls hideConfigurationOverlay(); the overlay's own
-            // cluster-change effect can then fire resetDeployment and bring it
-            // straight back, and ConfigureTestPanel stays null while it is up.
-            // Assert the panel really rendered, and re-drive the click if the
-            // overlay returned.
+            // Step 3: the configure-test-case step opens on its own once the deploy
+            // step completes (TestConfigurationPanel hides the setup overlay in an
+            // effect keyed on isDeployStepComplete). Wait for the panel that step
+            // renders; only if it stays closed -- e.g. the panel's own
+            // cluster-change effect fired resetDeployment and reopened setup -- fall
+            // back to clicking the step heading, which by then is enabled.
             await (0, test_1.expect)(async () => {
-                if (await configurationOverlay.isVisible()) {
-                    await configureScenarioButton.click({ timeout });
+                if (!(await configureTestPanel.isVisible())) {
+                    const canOpenConfigureStep = await configureStepHeading
+                        .isEnabled({ timeout: 5000 })
+                        .catch(() => false);
+                    if (canOpenConfigureStep) {
+                        await configureStepHeading.click({ timeout: 15000 });
+                    }
                 }
                 await (0, test_1.expect)(configureTestPanel).toBeVisible({ timeout: 15000 });
             }).toPass({ timeout: 90000 });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@camunda/e2e-test-suite",
-  "version": "0.0.1102",
+  "version": "0.0.1104",
   "description": "End-to-end test helpers for Camunda 8",
   "repository": {
     "type": "git",