@camunda/e2e-test-suite 0.0.1101 → 0.0.1103

package/README.md

@@ -406,7 +406,7 @@ MCP tests can still be run locally on macOS and Windows using the instructions a
 
 ## Automated Nightly Test Runs
 
-The test suite is configured to run automatically every night. The results of these nightly test runs are published on TestRail. If any test fails during these automated runs, the Designated Responsible Individual (DRI) of the project is notified via email for immediate attention and resolution. On a nightly basis, the test suite is configured to run the following tests:
+The test suite is configured to run automatically every night. The results of these nightly test runs are published as a Playwright HTML report artifact. If any test fails during these automated runs, the Designated Responsible Individual (DRI) of the project is notified via email for immediate attention and resolution. On a nightly basis, the test suite is configured to run the following tests:
 
 Failures are classified into categories (Infrastructure, Flaky, Product, Mixed) to aid triage.
 See [docs/ci-failure-categories.md](docs/ci-failure-categories.md) for the full model and criteria.
@@ -520,8 +520,8 @@ issues or instability, an HTML report automatically opens, facilitating in-depth
 
 ### On the CI:
 
-Within the CI environment, test results are accessible through TestRail, located in the C8 Project folder under Test
-Runs. These reports not only include detailed test results but also feature screenshots. In case of a test failure, you
+Within the CI environment, test results are accessible via the Playwright HTML report artifact attached to the
+GitHub Actions run. These reports not only include detailed test results but also feature screenshots. In case of a test failure, you
 will find the stacktrace. Furthermore, the CI environment offers extensive tools for in-depth analysis of test results
 and reports.
 
@@ -536,7 +536,7 @@ use: {
 ```
 
 Don't keep this enabled, or you'll blow up the disk space quickly. Files are recorded in the `test-results/videos`
-folder locally and to TestRail in the CI.
+folder locally and attached to the Playwright HTML report / uploaded as a build artifact in the CI.
 
 ## Contributing
 
@@ -613,35 +613,6 @@ Before marking a PR as ready for review:
 - [ ] Change scope is appropriate — large multi-version changes are split into separate PRs
 - [ ] A relevant test workflow has been run and **passed**
 - [ ] The workflow run URL is pasted in the PR description
-- [ ] If new tests were added: add the `testrail-test-case` label after the test run passes to auto-enrich TestRail cases (see [TestRail Integration](#testrail-integration)); update Confluence if applicable
-
-### TestRail Integration
-
-Test case documentation in TestRail is **automatically synced** from spec files. When a PR adds or modifies test cases, the sync workflow uses AI (GitHub Copilot) to generate human-readable step descriptions directly from the Playwright test code.
-
-#### How to trigger the sync
-
-**Option A — Label after a passing test run (recommended)**
-
-1. Run the relevant test workflow and confirm it passes.
-2. Add the `testrail-test-case` label to the PR.
-3. The [Sync TestRail Cases](https://github.com/camunda/c8-cross-component-e2e-tests/actions/workflows/sync-testrail-cases.yml) workflow fires automatically, detects the changed spec files, and enriches the matching TestRail cases with AI-generated steps.
-
-> Re-triggering is easy: remove the label and add it again.
-
-**Option B — Manual dispatch**
-
-Go to [Actions → Sync TestRail Cases → Run workflow](https://github.com/camunda/c8-cross-component-e2e-tests/actions/workflows/sync-testrail-cases.yml) and provide the version and spec file path manually. Useful for one-off enrichment without opening a PR.
-
-#### What the sync does
-
-- Finds the matching TestRail case by automation ID (set by the JUnit reporter) or normalised title.
-- Skips cases that already have steps on the correct template.
-- Re-enriches cases that are on the wrong TestRail template (fixes template + steps in one pass).
-- Calls the GitHub Copilot API to produce Action + Expected Result step rows from the raw Playwright code.
-
-#### Access
-
-If you do not have access to TestRail, contact the Test Automation Team to request access.
+- [ ] Update Confluence if applicable
 
 Thank you for using the C8 Cross-Component End-to-End Test Suite for Camunda C8 full product stack e2e testing. Happy testing! If you have any questions or need assistance, feel free to reach out to the maintainers for support.

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/test-setup.js

@@ -9,12 +9,9 @@ const crypto_1 = require("crypto");
 const axios_1 = __importDefault(require("axios"));
 const constants_1 = require("./utils/constants");
 async function captureScreenshot(page, testInfo) {
-    // Skip on passed/skipped: this ran for every test regardless of outcome,
-    // and since it's uploaded to TestRail via the testrail_attachment
-    // annotation below, a passing-test screenshot has negligible debugging
-    // value but was a dominant driver of excess TestRail attachment storage.
-    // Skip explicitly on passed/skipped rather than gating on
-    // `=== 'failed'`, so a timed-out or interrupted test -- exactly the
+    // Skip on passed/skipped: a passing-test screenshot has negligible
+    // debugging value. Skip explicitly on passed/skipped rather than gating
+    // on `=== 'failed'`, so a timed-out or interrupted test -- exactly the
     // cases where a screenshot is most useful -- still gets one.
     if (testInfo.status === 'passed' || testInfo.status === 'skipped') {
         return;
@@ -43,10 +40,6 @@ async function captureScreenshot(page, testInfo) {
         path: screenshotPath,
         contentType: 'image/png',
     });
-    testInfo.annotations.push({
-        type: 'testrail_attachment',
-        description: screenshotPath,
-    });
 }
 exports.captureScreenshot = captureScreenshot;
 async function captureFailureVideo(page, testInfo) {
@@ -65,10 +58,6 @@ async function captureFailureVideo(page, testInfo) {
             path: videoPath,
             contentType: 'video/webm',
         });
-        testInfo.annotations.push({
-            type: 'testrail_attachment',
-            description: videoPath,
-        });
     }
 }
 exports.captureFailureVideo = captureFailureVideo;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@camunda/e2e-test-suite",
-  "version": "0.0.1101",
+  "version": "0.0.1103",
   "description": "End-to-end test helpers for Camunda 8",
   "repository": {
     "type": "git",
@@ -22,7 +22,6 @@
     "access": "public"
   },
   "scripts": {
-    "sync-testrail": "node scripts/sync-testrail-cases.js",
     "test": "playwright test",
     "test:local": "node --env-file=.env ./runTest.js",
     "lint": "tsc && eslint . --ext .ts",

package/playwright.config.ts

@@ -10,7 +10,7 @@ if (!process.env.CAMUNDA_OPTIMIZE_BASE_URL && process.env.BASE_URL) {
 
 const projectName = process.env.PROJECT! || 'Chromium'; // Default to 'default-project' if PROJECT is not set
 
-const testRailOptions = {
+const junitOptions = {
   embedAnnotationsAsProperties: true,
   outputFile: './test-results/junit-report.xml',
 };
@@ -18,7 +18,7 @@ const testRailOptions = {
 // Define reporters without SlackReporter
 const useReportersWithoutSlack: any[] = [
   ['list'],
-  ['junit', testRailOptions],
+  ['junit', junitOptions],
   ['html', {outputFolder: 'html-report'}],
   ['json', {outputFile: `json-report/results.json`}],
 ];