Open kwin opened 1 year ago
Thanks for pointing this out, @kwin. We will add a link to the pipeline documentation that describes this.
@adobe export issue to Jira project CQDOC
:white_check_mark: Jira issue CQDOC-20147 is successfully created for this GitHub issue.
Thanks for the hint, just found it described at https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/using-cloud-manager/cicd-pipelines/configuring-production-pipelines.html?lang=en#full-stack-code. A link would be really helpful here :-).
Maybe you can also mention if those URLs are also considered for triggering automatic AEM updates.
Sorry, I didn't mean to only offer a hint. I read the comment as a rhetorical suggestion. The cross-linking was addressed in commit 9cd804e.
As for your comment about automatic AEM updates, I do not understand what you are asking. Could you please provide a bit more information?
The validation pipeline described in https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/deploying/aem-version-updates.html?lang=en uses https://github.com/adobe/frontend-regression-validator with certain content paths. I am wondering if those paths are the same as used for the experience audit or if not if there is another place in the UI where to maintain those.
Thank you for the further information, but I am still not following. The page you cite (https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/deploying/aem-version-updates.html) does not mention the frontend-regression validator or anything about paths, nor does the original page in question (https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/using-cloud-manager/test-results/experience-audit-testing.html).
This question might be better addressed to our support team.
The Support team asked me to provide a content page path for the release validation. That definitely deserves some more documentation and also if it is possible to configure that via UI (maybe sharing the same path as the experience audit pages). I am not sure the same paths can be leverage as for experience audit or that is something completely orthogonal but from a user's perspective it would make a lot of sense to reuse the same content for both purposes.
Issue in ./help/implementing/cloud-manager/experience-audit-testing.md
Currently only the standard publish root page is being measured. How to configure other pages to be audited?