netcentric / aem-cloud-validator Goto Github PK

Currently the ITs fail on Windows due to different path separators.

There shouldn't be a local longCacheKey used with client libs as this is set globally (https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/content-delivery/caching.html?lang=en#content-consistency)

Currently only internal install hooks are detected and prevented in mutable content packages. External hooks should be detected as well.

Packages containing nodes below /libs are not allowed to be deployed in Cloud Manager.
A rule enforcing this should be added.
It needs to be configurable though, to be also usable e.g. for Core WCM Components which is part of the product (i.e. is allowed in /libs).

You must not make changes in the /libs branch
Any changes you do make may be lost, because this branch is liable to changes whenever upgrades are applied to your instance.

(https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/developing/full-stack/overlays.html?lang=en#developing)

See the related tickets:
adobe/aemanalyser-maven-plugin#31
adobe/aemanalyser-maven-plugin#27

They currently fail because they cannot access the GITHUB_TOKEN nor SONAR_TOKEN (as both are secrets). Probably switching to https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#pull_request_target is required.

In addition GH actions should build with Java 8, 11, 17 on Linux, Windows and Mac.

https://docs.adobe.com/content/help/en/experience-manager-learn/cloud-service/debugging/debugging-aem-as-a-cloud-service/build-and-deployment.html#including-var-in-content-package

(e.g. observed in the context of Adobe-Consulting-Services/acs-aem-commons#2341)

Mutable content packages are deployed to publish via replication from author in AEMaaCS.
In case they contain an install hook the replication fails, as the replication-receiver system user does neither have admin privileges and nor is configured as allowed user for install hooks (compare with https://issues.apache.org/jira/browse/JCRVLT-427). This limitation is currently not documented at https://experienceleague.adobe.com/docs/experience-manager-learn/cloud-service/debugging/debugging-aem-as-a-cloud-service/build-and-deployment.html?lang=en#debugging but having a mutable package with an install hook leads to a failed deployment.

The option allowReadOnlyMutablePaths does not work since the validator emits the error disregarding its value when the package is not an author-only package.
A small change in the condition is needed for this option to work correctly.

to reproduce:
set the option allowReadOnlyMutablePaths in a project that contains content in a mutable path (e.g. /var). the validator will still fail because of the mutable path.

When developing with the AEM SDK, a common approach is to use InstallHook's to trigger actions when a mutable content package is installed. This is for example done by the Netcentric accesscontroltool. To make it possible to leverage this capability, there should be an option to disable the error for install hooks in mutable content for local development

All "property" index definitions are just disregarded. Only "lucene" definitions are properly supported.

Limitations
Index management is currently only supported for indexes of type lucene.

(https://experienceleague.adobe.com/docs/experience-manager-cloud-service/operations/indexing.html?lang=en#index-management-using-blue-green-deployments)

According to Adobe-Consulting-Services/acs-aem-commons#2523 (comment) the system user which is installing packages on the publish has very limited privileges.

Currently this is

"# GRANITE-23007 - [RTC] Configure service user mapping for Pipeline replication",
    "create service user sling-distribution-importer with path system/cq:services/internal",
    "set principal ACL for sling-distribution-importer",
    "  allow jcr:modifyAccessControl,jcr:readAccessControl on /content",
    "  allow jcr:modifyAccessControl,jcr:readAccessControl on /conf",
    "  allow jcr:modifyAccessControl,jcr:readAccessControl on /etc",
    "  allow jcr:nodeTypeDefinitionManagement,rep:privilegeManagement on :repository ",
    "end",

(https://repo1.maven.org/maven2/com/adobe/aem/aem-sdk-api/2021.1.4830.20210128T075814Z-210128/aem-sdk-api-2021.1.4830.20210128T075814Z-210128-aem-publish-sdk.slingosgifeature)

It is unclear though why authorizables and ACLs below /home don't lead to exception on publish....

According to https://experienceleague.adobe.com/docs/experience-manager-cloud-service/operations/indexing.html?lang=en#how-to-use every new index has to follow a certain namespace schema. Index definitions named differently won't be installed.

Content packages of type "mixed" are only installed during the Cloud Manager "Build Images" step. That means, that all mutable content being installed through these packages is lost, as those packages are never reinstalled once the kubernetes pod is started with the live content!

Currently this doesn't lead to any error in Cloud Manager despite what is stated in https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/deploying/overview.html?lang=en#deploying-content-packages-via-cloud-manager-and-package-manager

Content packages written for AEM as a Cloud Service applications must have a clean separation between immutable and > mutable content and Cloud Manager will enforce it by failing the build, outputting a message like:

Generated content-package <PACKAGE_ID> located in file is of MIXED type

Next to the Unit test we should have a proper IT. Probably using maven-invoker-plugin is the easiest way to check in the context of a Maven build with filevault-package-maven-plugin.

Using package type "content" leads to the index not properly being considered as it is installed too late.