Build environment 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.

As a result of this security enhancement, some users may face issues during the build step, particularly 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 growing 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 should 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 migrate to building with Java 21 or Java 17, you must first upgrade to the latest SonarQube version. For details, 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.

We recommend the following deployment strategy:

About some translation features translation-features

The following features might 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 is used for builds with Java 21 and Java 17, and it will gradually be applied to Java 11 builds too (see the Note below). An environment must be on AEM release 17098 or more recent to receive the Java 21 update. To ensure compatibility, the following adjustments are required.

Library updates can be applied anytime, as they remain compatible with older Java versions.

The AEM Cloud Service SDK is compatible with Java 21 and can be used to validate the compatibility of your project with Java 21 before executing 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

You may find it necessary to vary 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 may be preferred for various environments. A development build might use 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 might require specific configuration variables that should not be stored in the Git repository. Additionally, you may 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 may invoke 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 should generally be 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.