Expand my Community achievements bar.

July 31st AEM Gems Webinar: Elevate your AEM development to master the integration of private GitHub repositories within AEM Cloud Manager.
SOLVED

Environment specific configuration is not working in AEMaaCS

Avatar

Level 9

In order to keep RepositoryInitializer configuration only on stage, I placed the file org.apache.sling.jcr.repoinit.RepositoryInitializer-test.config in config.author.stage alone. But after the production environment, I was able to see the script executed in both stages and production. The only environment where it should exist is the stage environment.

 

 

Mario248_0-1671517597074.png

 

Am I missing any config here ?

 

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

That's a special combination of AEM as a Cloud Service with the Repository Initializer, and it's working as expected. Let me explain the details why this is working as expected.

 

In AEM CS the production instances are always identical to the Stage instances (from an application point of view, meaning /apps and /libs). That means that the AEM images are built once and the deployed to Stage and PROD (as part of the deployment process).

Now, these images are immutable during runtime. That means that any change in /apps and /libs must be executed during the build-image phase of the pipeline. The biggest part is the addition of your application into /apps, but there is also the usecase that some ACLs need to be applied at this phase to /apps and /libs. That means that the repoinit scripts must be executed at the build time already. 

(But on the other hand side, I am not totally sure if at that buildtime already a runmode is respected ... it would make sense though.)

 

 

Ok, is this a problem? Normally it should not, because your Stage should be identical to PROD. That means if you want to add any ACL to /apps and/or /libs, you should do it in both cases. And later on you can adjust via group memberships if these ACLs are really taking effect.

 

That means that during stage build these scripts are applied, and you get the same image in PROD.

 

View solution in original post

3 Replies

Avatar

Community Advisor

Hi @Mario248 
IMO, config.author.stage is right one and should apply to Stage only.

- Have you verified the configuration in Developer console on prod?
- Have you double checked if by any chance it's not present in config folder?
 
Thanks,
Himanshu Singhal

Avatar

Level 9

- Have you verified the configuration in Developer console on prod? - Yes verified configuration dump. There is no entry but whatever script I have repoinit that was triggered and created users based on initscript


- Have you double checked if by any chance it's not present in config folder? - Yes, I kept this json file only on config.author.stage

Avatar

Correct answer by
Employee Advisor

That's a special combination of AEM as a Cloud Service with the Repository Initializer, and it's working as expected. Let me explain the details why this is working as expected.

 

In AEM CS the production instances are always identical to the Stage instances (from an application point of view, meaning /apps and /libs). That means that the AEM images are built once and the deployed to Stage and PROD (as part of the deployment process).

Now, these images are immutable during runtime. That means that any change in /apps and /libs must be executed during the build-image phase of the pipeline. The biggest part is the addition of your application into /apps, but there is also the usecase that some ACLs need to be applied at this phase to /apps and /libs. That means that the repoinit scripts must be executed at the build time already. 

(But on the other hand side, I am not totally sure if at that buildtime already a runmode is respected ... it would make sense though.)

 

 

Ok, is this a problem? Normally it should not, because your Stage should be identical to PROD. That means if you want to add any ACL to /apps and/or /libs, you should do it in both cases. And later on you can adjust via group memberships if these ACLs are really taking effect.

 

That means that during stage build these scripts are applied, and you get the same image in PROD.