Build environment of Cloud Manager build-environment

Learn about Cloud Manager’s build environment and how it builds and tests your code.

Build environment details build-environment-details

Cloud Manager builds and tests your code using a specialized build environment.

HTTPS Maven repositories https-maven

Cloud Manager release 2023.10.0 began a rolling update to the build environment (completing with release 2023.12.0), which included an update to Maven 3.8.8. A significant change introduced in Maven 3.8.1 was a security enhancement aimed at mitigating potential vulnerabilities. Specifically, Maven now disables all insecure http://* mirrors by default, as outlined in the Maven release notes.

Some users encounter issues during the build step when downloading artifacts from Maven repositories that use insecure HTTP connections.

To ensure a smooth experience with the updated version, Adobe recommends that users update their Maven repositories to use HTTPS instead of HTTP. This adjustment aligns with the industry’s shift towards secure communication protocols and helps maintain a secure and reliable build process.

Use a specific Java version using-java-support

The Cloud Manager build process uses the Oracle 8 JDK to build projects by default, but AEM Cloud Service customers set the Maven execution JDK version to 21 (preferred), 17, or 11.

Set the Maven JDK version alternate-maven-jdk-version

To set the Maven execution JDK, create a file named .cloudmanager/java-version in the Git repository branch used by the pipeline. Edit the file so that it contains only the text, 21 or 17. While Cloud Manager also accepts a value of 8, this version is no longer supported for AEM Cloud Service projects. Any other value is ignored. When 21 or 17 is specified, Oracle Java 21 or Oracle Java 17 is used.

Prerequisites for migrating to building with Java 21 or Java 17 prereq-for-building

To build with Java 21 or Java 17, Cloud Manager now uses SonarQube 9.9, which is compatible with these Java versions. This change was introduced in Cloud Manager release 2025.1.0. No customer action is required to upgrade SonarQube. For more details and to understand the change, see the Release Notes for Cloud Manager 2025.1.0.

When migrating your application to a new Java build version and runtime version, thoroughly test in dev and stage environments before deploying to production.

Adobe recommends the following deployment strategy:

Translation features translation-features

The following features do not function correctly when deployed on the Java 21 runtime, and Adobe expects to resolve them by early 2025:

Runtime requirements runtime-requirements

The Java 21 runtime has been applied to all eligible environments, which are environments on AEM release 17098 or later that satisfy the criteria below. If an environment does not meet the criteria, it is important to make adjustments in order to ensure performance, availability, and security.

The AEM Cloud Service SDK supports Java 21 and lets you verify your project’s compatibility with Java 21 before running a Cloud Manager pipeline.

Build time requirements build-time-reqs

The following adjustments are required to allow building the project with Java 21 and Java 17. They can be updated even before you are running Java 21 and Java 17 because they are compatible with older Java versions.

AEM Cloud Service customers are recommended to build their projects with Java 21 as early as possible to take advantage of new language features.

<project>
  ...
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-scr-plugin</artifactId>
        <version>1.26.4</version>
        <executions>
          <execution>
            <id>generate-scr-scrdescriptor</id>
            <goals>
              <goal>scr</goal>
            </goals>
          </execution>
        </executions>
        <dependencies>
          <dependency>
            <groupId>org.ow2.asm</groupId>
            <artifactId>asm-analysis</artifactId>
            <version>9.7.1</version>
            <scope>compile</scope>
          </dependency>
        </dependencies>
      </plugin>
      ...
    </plugins>
    ...
  </build>
  ...
</project>

Environment variables - standard environment-variables

Configure the build process based on information about the program or pipeline.

For instance, if JavaScript minification occurs at build time using a tool like gulp, different minification levels are preferred for various environments. A development build uses a lighter minification level compared to staging and production.

To support this, Cloud Manager adds these standard environment variables to the build container for every execution.

Environment variables - pipeline pipeline-variables

Your build process requires specific configuration variables that are not stored in the Git repository. Additionally, you need to adjust these variables between pipeline executions using the same branch.

See also Configure Pipeline Variables for more information.

Install additional system packages installing-additional-system-packages

Some builds require additional system packages to function fully. For example, a build invokes a Python or Ruby script and must have an appropriate language interpreter installed. This installation process can be managed by calling the exec-maven-plugin in your pom.xml to invoke APT. This execution is wrapped in a Cloud Manager-specific Maven profile. This example installs Python.

        <profile>
            <id>install-python</id>
            <activation>
                <property>
                        <name>env.CM_BUILD</name>
                </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>exec-maven-plugin</artifactId>
                        <version>1.6.0</version>
                        <executions>
                            <execution>
                                <id>apt-get-update</id>
                                <phase>validate</phase>
                                <goals>
                                    <goal>exec</goal>
                                </goals>
                                <configuration>
                                    <executable>apt-get</executable>
                                    <arguments>
                                        <argument>update</argument>
                                    </arguments>
                                </configuration>
                            </execution>
                            <execution>
                                <id>install-python</id>
                                <phase>validate</phase>
                                <goals>
                                    <goal>exec</goal>
                                </goals>
                                <configuration>
                                    <executable>apt-get</executable>
                                    <arguments>
                                        <argument>install</argument>
                                        <argument>-y</argument>
                                        <argument>--no-install-recommends</argument>
                                        <argument>python</argument>
                                    </arguments>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>

This same technique can be used to install language-specific packages, for example, using gem for RubyGems or pip for Python Packages.