Environment specific configuration is not working in AEMaaCS | Community
Skip to main content
Mario248
Level 7
December 20, 2022
Solved

Environment specific configuration is not working in AEMaaCS

  • December 20, 2022
  • 2 replies
  • 1192 views

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.

 

 

 

Am I missing any config here ?

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

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.

 

2 replies

Himanshu_Singhal
Community Advisor
Community Advisor
December 20, 2022

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

Mario248
Mario248Author
Level 7
December 20, 2022

- 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

joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
December 26, 2022

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.