feat(dotcms-ui-e2e): Make run E2E inside Nx

[oidacra]

• Updated Jest configuration to include coverage reporters and JUnit output.
• Introduced Playwright configuration for different environments (dev, ci, local) with headless options.
• Added new components and locators for better test organization.
• Implemented login functionality and various test cases for login scenarios, including valid and invalid credentials.
• Created environment configuration for managing base URLs and server reuse.
• Added utility functions for waiting on locators and generating base64 credentials.

This update improves the structure and reliability of end-to-end tests for the dotCMS UI.

#32525

[github-actions]

❌ Issue Linking Required

This PR could not be linked to an issue. All PRs must be linked to an issue for tracking purposes.

How to fix this:

Option 1: Add keyword to PR body (Recommended - auto-removes this comment)
Edit this PR description and add one of these lines:

• This PR fixes #123 or Fixes: #123

• This PR closes #123 or Closes: #123

• This PR resolves #123 or Resolves: #123

• Other supported keywords: fix, fixed, close, closed, resolve, resolved
  Option 2: Link via GitHub UI (Note: won't clear the failed check)

1. Go to the PR → Development section (right sidebar)

2. Click "Link issue" and select an existing issue

3. Push a new commit or re-run the workflow to clear the failed check
   Option 3: Use branch naming
   Create a new branch with one of these patterns:

• 123-feature-description (number at start)

• issue-123-feature-description (issue-number at start)

• feature-issue-123 (issue-number anywhere)

Why is this required?

Issue linking ensures proper tracking, documentation, and helps maintain project history. It connects your code changes to the problem they solve.---

This comment was automatically generated by the issue linking workflow

[semgrep-code-dotcms-test]

Legal Risk

The following dependencies were released under a license that
has been flagged by your organization for consideration.

Recommendation

While merging is not directly blocked, it's best to pause and consider what it means to use this license before continuing. If you are unsure, reach out to your security team or Semgrep admin to address this issue.

MPL-2.0

• dompurify 3.2.7

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This PR was closed because it has been stalled with no activity.

[semgrep-code-dotcms-test]

Legal Risk

The following dependencies were released under a license that
has been flagged by your organization for consideration.

Recommendation

While merging is not directly blocked, it's best to pause and consider what it means to use this license before continuing. If you are unsure, reach out to your security team or Semgrep admin to address this issue.

GPL-2.0

• node-forge 1.3.1

MPL-2.0

• axe-core 4.10.3
• dompurify 3.2.7

[semgrep-code-dotcms-test]

Legal Risk

The following dependencies were released under a license that
has been flagged by your organization for consideration.

Recommendation

While merging is not directly blocked, it's best to pause and consider what it means to use this license before continuing. If you are unsure, reach out to your security team or Semgrep admin to address this issue.

MPL-2.0

• axe-core 4.11.1

[spbolton]

This seems like active work without a related Issue to track it. Should we have an issue for this otherwise it is invisible to the sprint or any other epic it may relate to.

[erickgonzalez]

@spbolton, since this PR was created a long time ago, and was forgotten. We created this GH issue #34561 to bring it back to life.

[spbolton]

@spbolton, since this PR was created a long time ago, and was forgotten. We created this GH issue #34561 to bring it back to life.

Note though the keyword format in the Issue Linking Required comment, you cannot just add the issue number. There are specific keywords required e.g. fixes,closes,resolves to link properly a PR to an issue https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests . If these are followed in the message then the issue gets added to the development section on the right panel. The issue can also be added there manually. We do have a workflow that identifies the issue from the branch name if the branch name itself contains the issue number, but it only runs on pr create currently and has some issues I am looking to address.

Note, that although this creates the relationship, we have disabled the option now available so that it does not actually close the issue until we manually close it, but this is still important to maintain the relationship and it is different than just a reference in the body.

[erickgonzalez]

@spbolton yes, in this case we'll have to manually link it to the GH issue (done), but thanks for the heads up. Since we got you here, can you take a look at the changes related to the GHA?

[spbolton]

There are cases where the image build does not even occur, when the changes neither impact frontend of backend code. In these cases running e2e tests would not even work. There is a "build" flag we can rely on to at least only run e2e tests where the PR does build.

e2e: ${{ fromJSON(needs.initialize.outputs.filters).build == 'true' }}

[spbolton]

I am further reviewing issues that can come from moving the location of the dotcms-ui-e2e within the core-web folder structure. the e2e tests depende upon the core build, and core has core-web as a dependency due to packaging it up into the image. Putting the e2e module under core-web implies that it might be a sub module to the core-web module. At a minimum this breaks convention and makes a confusing difference between the maven module heierarchy and its folder structure, I am looking further though it may also impose complications to the hierarchy that cause coupling and other relationship issues.

This is a review of the issue and best practice here. Should be a simple change.

The Issue: Misleading Maven Module Placement

core-web/apps/dotcms-ui-e2e/pom.xml lives inside core-web/, which signals to any developer reading the repo that this module is a child of core-web. It isn't — there is no circular dependency here, the root pom.xml correctly declares it after dotCMS:

<module>core-web</module>
<module>dotCMS</module>                          <!-- image built here -->
<module>core-web/apps/dotcms-ui-e2e</module>    <!-- runs after image exists ✅ -->

The risk is a frontend developer (whose mental model of the repo is core-web/) seeing the pom.xml sitting alongside their Angular projects and assuming it belongs to the core-web Maven module. If they add it to core-web/pom.xml as a submodule, the E2E tests will attempt to run before the Docker image is built and fail in a non-obvious way.

The Nx Coupling Constraint

The test code itself must stay in core-web/apps/dotcms-ui-e2e/ — it has hard couplings to the core-web Nx workspace:

File	Coupling
project.json	implicitDependencies: ["dotcms-ui"] — Nx workspace reference
tsconfig.json	extends: "../../tsconfig.base.json" — relative path to core-web/
project.json	@nx/playwright:playwright executor requires workspace membership

Moving the test source files is not viable without re-architecting the Nx setup.

Proposed Solution: Split Maven Ownership from Nx Project Location

Keep all test code and project.json where they are. Move only the pom.xml to e2e/dotcms-ui-e2e/pom.xml, pointing back at the Nx project:

e2e/
  dotcms-e2e-java/          ← already here
  dotcms-ui-e2e/            ← new
    pom.xml                 ← executes: nx run dotcms-ui-e2e:e2e
                               from workingDir: ../../core-web
core-web/
  apps/
    dotcms-ui-e2e/          ← Nx project stays here (no change to test code)
      src/
      project.json
      playwright.config.ts
      tsconfig.json
      (no pom.xml)

Root pom.xml module order becomes:

<module>core-web</module>
<module>dotCMS</module>
<module>e2e/dotcms-e2e-java</module>
<module>e2e/dotcms-ui-e2e</module>   <!-- sits alongside Java E2E, clearly post-image -->

This makes the dependency story readable at a glance and puts the Maven lifecycle where frontend developers won't accidentally touch it.

---

Happy to pair on this if helpful — the change to the pom.xml itself is small, the main work is the directory move and updating the workingDir reference in the Maven exec configuration.