When you execute mvn clean verify -Pui-tests-docker-execution -DAEM_AUTHOR_URL=https://author.my-deployment.com (notice the additional clean phase) it fails with

[INFO] --- exec:1.6.0:exec (docker-compose-up) @ com.adobe.cq.cloud.testing.ui.java.ui.tests ---
 Container ui-selenium-webdriver-selenium-chrome-1  Created
 Container ui-selenium-webdriver-tests-1  Created
Attaching to selenium-chrome-1, tests-1
Gracefully stopping... (press Ctrl+C again to force)
Error response from daemon: error while creating mount source path '/Users/konradwindszus/git/adobe/aem-test-samples/ui-selenium-webdriver/target/reports': chown /Users/konradwindszus/git/adobe/aem-test-samples/ui-selenium-webdriver/target/reports: permission denied
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)

This is due to the fact that in this case the parent directory target has been deleted. You should always ensure that the target is there even if no docker build has happened in that directory.

Expected Behaviour

Documentation written in a way everyone could follow and understand it.

Actual Behaviour

I've been trying to follow the documentation to integrate Selenium Webdriver into my project generated with a Maven archetype on a AEMaaCS environment and I can say that it's hardly impossible to follow the documentation and make it works.

Reproduce Scenario (including but not limited to)

Steps to Reproduce

1- Create a new AEM local instance using AEMaaCS latest SDK from Software Distribution
2- Generate your sourcecode using Maven archetype 41
3- Trying to modify the ui.test module on your project and use the Selenium-Webdriver from aem-test-samples repo FOLLOWING the README and make it works.

Platform and Version

Sample Code that illustrates the problem

Logs taken while reproducing problem

this is a sample issue

Currently ReplicationIT does not support testing replication(activate/deactivate) on a preview agent. The replication actions sould be tested on preview agent also if the agent is available.

When executing the first step from https://github.com/adobe/aem-test-samples/blob/aem-cloud/ui-selenium-webdriver/README.md#all-in-one with Maven 3.9.6 you run into the following error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install) on project com.adobe.cq.cloud.testing.ui.java.ui.tests: The packaging plugin for this project did not assign a main file to the project but it has attachments. Change packaging to 'pom'. -> [Help 1]

This is a new error in introduced with maven-install-plugin 3.0 (https://issues.apache.org/jira/browse/MINSTALL-118). The fix is to convert the packaging to pom.

In addition it is probably never useful to deploy anything for this project to a Maven repository therefore it would be useful to disable it with

<build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <artifactId>maven-deploy-plugin</artifactId>
                    <configuration>
                        <skip>true</skip>
                    </configuration>
                </plugin>
                <plugin>
                    <artifactId>maven-install-plugin</artifactId>
                    <configuration>
                        <skip>true</skip>
                    </configuration>
                </plugin>
.....

In cases that the tests of ReplicationIT time out, the error message should be more descriptive. So instead of breaking becuause of a timeout it should hint to check the replication queues.
An additional potential root cause could be that the path is not allowed to get accessed by the dispatcher configuration.

Team - I am trying to upgrade thecypress version from 12.17.0 to 13.13.3. This is based on the latest version available in docker-hub.

Expected Behaviour

The docker image should build fine without any error.

Actual Behaviour

The docker image is not getting built and is giving an error as follows:

ESC[91mW: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/microsoft-edge-stable.list:1 and /etc/apt/sources.list.d/microsoft-edge.list:3
W: Target Packages (main/binary-all/Packages) is configured multiple times in /etc/apt/sources.list.d/microsoft-edge-stable.list:1 and /etc/apt/sources.list.d/microsoft-edge.list:3
E: Package 'python' has no installation candidate
ESC[0mThe command '/bin/sh -c apt -qqy update     && apt -qqy --no-install-recommends install     python     build-essential' returned a non-zero code: 100
2024/08/19 09:55:38 Container failed during run: build. No retries remaining.
failed to run step ID: build: exit status 100

Reproduce Scenario (including but not limited to)

We are on AEMaaCS and the error is coming in the cloud pipeline, during the build-images step, for the ui.tests module.

Steps to Reproduce

Run the docker build, using the Dockerfile with cypress version set to 13.13.3

Platform and Version

AEMaaCS SDK version: 2024.7.17258.20240726T172406Z

Sample Code that illustrates the problem

https://github.com/adobe/aem-test-samples/blob/aem-cloud/ui-cypress/Dockerfile

Logs taken while reproducing problem

Shared above

Although the README in https://github.com/adobe/aem-test-samples/tree/aem-cloud/ui-selenium-webdriver#locally-standalone mentions a Maven profile named ui-tests-local-execution, this is not defined in the effective POM. Therefore the local execution does not work as described.

SearchIT performs what appears to be a pretty basic search, but the CQClient.searchInPages() method that it calls relies on the long-deprecated com.day.cq.wcm.core.impl.servlets.FindReplaceServlet, which constructs an XPath query that is not optimized to leverage any product index definitions (no nodetype predicate, leading wildcard for the jcr:like expression, etc.).

It turns out that during the Cloud Manager Product Tests phase, successful execution of this test actually depends on the query engine choosing traversal, because an nt:base index definition scoped to the entire repository takes too long to update for the product test page creation to be reflected in the index before the test timeout.

This issue represents a frequent blocker for deploying product upgrades to some customers who have deployed an nt:base index definition, and it should simply be disabled as it does not truly demonstrate that supported product behavior is working.

Expected Behaviour

assets.cy.js >> @completeupload should complete successfully, when the image path and previous steps are correct

Actual Behaviour

assets.cy.js >> @completeupload times-out while the status of asset upload is 'Processing'

Steps to Reproduce

npx cypress run --headed --no-exit --browser chrome >> reports timeout for @completeupload step

Enhancement Proposal

Instead of cy.wait, we can rather invoke the more deterministic cy.waitUntil - as follows:

    // wait for the /content/dam.completeUpload.json POST to complete before polling for the asset
    cy.waitUntil(
        () => ['@completeupload'], {
          errorMsg: `asset ${imagePath} should be uploaded`,
          timeout: 5000,
          interval: 1000
        }
    );

Please let me know if this looks ok - will accordingly raise a PR.

Expected Behaviour

We have experienced on multiple occasions that custom project code has overridden CORS/CSRF/Sling Filter configs that conflicts with the respective OOTB AEM configurations. Duet to which following APIs request gets blocked:

POST/libs/dam/cfm/headless/endpoints/content/graphql.json
POST/libs/dam/cfm/headless/endpoints/content/graphql.A.json

For e.g. WKND Site has overridden these configs. Created an issue#301

As part of this issue, we should add the Product Functional tests to ensure:
A. the backend headless APIs (GraphQL) should not break due to custom configurations.
B. Headless Admin App is getting loaded with a repo pointing to the AEM CS author environment through IMS user

NOTE: The backend headless APIs (GraphQL) is supported under specific FT. Ensure the feature is enabled before running the tests.

Actual Behaviour

Reproduce Scenario (including but not limited to)

Steps to Reproduce

Platform and Version

Sample Code that illustrates the problem

Logs taken while reproducing problem

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• Update dependency org.apache.maven.plugins:maven-install-plugin to v3.1.3
• Update dependency org.awaitility:awaitility to v4.2.2
• Update dependency org.apache.maven.plugins:maven-jar-plugin to v3.4.2
• Update dependency org.apache.maven.plugins:maven-javadoc-plugin to v3.10.0
• Update dependency org.apache.maven.plugins:maven-resources-plugin to v3.3.1
• Update dependency org.apache.maven.plugins:maven-surefire-plugin to v3.5.0
• Update dependency org.apache.maven.plugins:maven-surefire-report-plugin to v3.5.0
• Update dependency org.codehaus.mojo:exec-maven-plugin to v3.4.1
• Update dependency org.seleniumhq.selenium:selenium-java to v4.24.0
• Update maven Docker tag to v3.9.9
• Update cypress/included Docker tag to v13
• Update dependency cypress to v13
• Update dependency cypress-fail-on-console-error to v5
• Update dependency cypress-terminal-report to v6
• Update dependency org.slf4j:slf4j-simple to v2
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update cypress/included Docker tag to v12.17.4
• Update dependency cypress to v12.17.4
• Update dependency cypress-multi-reporters to v1.6.4
• Update dependency cypress-terminal-report to v5.3.12
• Update dependency mocha-junit-reporter to v2.2.1
• Update dependency commons-io:commons-io to v2.16.1
• Update dependency org.apache.maven.plugins:maven-assembly-plugin to v3.7.1
• Update dependency org.apache.maven.plugins:maven-clean-plugin to v3.4.0
• Update dependency org.apache.maven.plugins:maven-enforcer-plugin to v3.5.0
• Update dependency org.apache.maven.plugins:maven-failsafe-plugin to v3.5.0
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

The current ReplicationIT test implementation has fundamental issues

1. It creates test pages in the customer content. This breaks a contract because the product edits content in the customer space. In some edge cases, test pages can end up published.
2. It tests publishing infrastructure (CDN, dispatcher) that is out of scope for the Replication feature. The dispatcher and parts of the CDN are owned by the customer, so a wrong customer configuration can fail the product test.

If testing the publishing infrastructure is required, it should be done at project level because most of the infra is owned by the customer.

Regarding ReplicationIT, it should be rewritten in a way that it only uses information available on author. It's possible to do so, because the Replication framework does provide the status of individual replication actions on author. Also, the test would effectively cover more Replication feature than the current implementation.

(a) Instead of creating new pages in the customer content space, do replicate a path in the immutable content such as /libs.
(b) Instead of checking for replication status by polling the publish tier, do check for status on author either via events or via the replication queues.