For customer’s using Adobe Managed Services, Cloud Manager has become the de facto system for deploying code to their Adobe Experience Manager environments. Among Cloud Manager’s many deficiencies is the inability to fetch artifacts from private remote repositories.
The good news is there’s a workaround for internet-facing artifact repositories. Unfortunately, non-internet facing artifact repositories are not supported as Cloud Manager spins up Docker containers to run the actual build process and they do not support a pool of IPs or virtual networks for the containers. According to feedback from Adobe, the Cloud Manager team is waiting on a feature from Microsoft Azure to allow all Cloud Manager Containers to be assigned an IP address out of a defined range. Once this feature is added to Azure, AMS will be able to provide an IP range to allow access to the artifact server.
Why Would I Want to Do This?
I think it’s certainly worth asking: why not just follow Adobe’s model with Cloud Manager and put everything in one big Maven project?
There are a few good reasons you may not want to follow the Adobe pattern:
- You are a larger enterprise and have multiple teams working on multiple different projects in parallel and consolidating on a single project would make releases and merging very difficult to manage
- You have integrations or dependencies on upstream teams for things like service connections, UI frameworks or custom integrations
- You want to integrate additional checks into your code not supported in Adobe Cloud Manager, but don’t want to have to run a build twice
Connecting to a Private Artifact Repository
The solution involves two parts:
- Working with your CSE to configure Environment Variables
- Overriding the settings.xml in the project
Custom Environment Variables
First, Adobe has a feature where your CSE can request the provisioning of Custom Environment variables, this allows you to specify private variables such as the connection URL, username or password. This will require your CSE to open a support ticket with an internal team at Adobe, so you will simply need to provide the keys and values to the CSE to open the ticket.
According to an inside source, this may come as a feature in the API, which is currently available but not supported in Cloud Manager.
Edit: Custom variables are now available as Pipeline Variables which can be specified in the Adobe I/O CLI.
Setting Your Artifact Server
In order to resolve the dependencies from your private repository, Maven needs three configuration steps.
First, add the repository into the pom.xml, for example:
Next, you’ll need to override the settings.xml to do this, create a file in the root of the project called .mvn/maven.config with the contents:
-s ./settings.xml
This will instruct Maven to use a settings.xml file located in the project directory.
Finally, create a settings.xml and use the Custom Environment variables to set the username and password for the server (the ID must match the pom.xml) as well as providing the default adobe-public artifact repository:
Once all the configurations are in place, trigger a Cloud Manager build and you should see Cloud Manager connecting to your private artifact repository to download the dependencies for the project.
Want to learn more about Cloud Manager?
You may want to check out my latest Cloud Manager post on diagnosing Cloud Manager dispatcher deployment issues.
Dan,
Nice article! I think this is great when it comes to “shared” artifacts. Lets say I have a global project, then have ProjectA, ProjectB, ProjectC and each of them need Global Project. So your solution would allow all the project’s pull “private repo” of global, but it doesn’t affect the issue that when I do a deployment for only ProjectA, all projects would have to build? We have a 5 different projects on github right now, so I am trying to find the best solution with Cloud manager.
Thanks,
Sean
@Sean,
I didn’t explicitly describe it in the article, but our project was set up to invert the process where ProjectA, ProjectB, and ProjectC were built and exposed outside of AMS and they were referenced as released artifacts from the Global project. It does mean that every project is deployed with each build, however it allows multiple teams to work concurrently on different codebases which otherwise isn’t possible with Cloud Manager.
Dan,
As per the solution the dependent artifact will not pass through the pipeline?
And,
If i have a Project B and Project C which are dependent on Project A…then how can allow them to accommodate them in single repository in cloud manager
@Sravs,
As long as the dependencies can be resolved from the artifact repository, Maven should be able to retrieve transient dependencies during the Cloud Manager build.
-Dan