Adobe

Pulling Private Dependencies with Cloud Manager

Cloud Manager Private Artifacts Hero

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.

The Digital Essentials, Part 3
The Digital Essentials, Part 3

Developing a robust digital strategy is both a challenge and an opportunity. Part 3 of the Digital Essentials series explores five of the essential technology-driven experiences customers expect, which you may be missing or not fully utilizing.

Get the Guide

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.

About the Author

Dan is a certified Adobe Digital Marketing Technologist, Architect, and Advisor, having led multiple successful digital marketing programs on the Adobe Experience Cloud. He's passionate about solving complex problems and building innovative digital marketing solutions. Dan is a PMC Member of the Apache Sling project, frequent Adobe Beta participant and committer to ACS AEM Commons, allowing a unique insight into the cutting edge of the Adobe Experience Cloud platform.

More from this Author

Thoughts on “Pulling Private Dependencies with Cloud Manager”

  1. 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

  2. @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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to the Weekly Blog Digest:

Sign Up