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.

Using a Specific Java Version using-java-support

By default, projects are built by the Cloud Manager build process using the Oracle 8 JDK. Customers wanting to use an alternate JDK have two options.

Maven Toolchains maven-toolchains

The Maven Toolchains Plugin allows projects to select a specific JDK (or toolchain) to be used in the context of toolchains-aware Maven plugins. This is done in the project’s pom.xml file by specifying a vendor and version value.

This toolchain plugin can be added as part of a profile as shown below.

<profile>
    <id>cm-java-11</id>
    <activation>
        <property>
            <name>env.CM_BUILD</name>
        </property>
    </activation>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-toolchains-plugin</artifactId>
                <version>1.1</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>toolchain</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <toolchains>
                        <jdk>
                            <version>11</version>
                            <vendor>oracle</vendor>
                        </jdk>
                    </toolchains>
                </configuration>
            </plugin>
        </plugins>
    </build>
</profile>

This will cause all toolchains-aware Maven plugins to use the Oracle JDK, version 11.

When using this method, Maven itself still runs using the default JDK (Oracle 8) and the JAVA_HOME environment variable is not changed. Therefore checking or enforcing the Java version through plugins like the Apache Maven Enforcer Plugin does not work and such plugins must not be used.

The currently available vendor/version combinations are:

This table refers to the product version numbers. Java build numbers or installation paths may reflect old Java version conventions such as 1.8 for Java 8.

Alternate Maven Execution JDK Version alternate-maven-jdk-version

It is also possible to select Java 8 or Java 11 as the JDK for the entire Maven execution. Unlike the toolchains options, this changes the JDK used for all plugins unless the toolchains configuration is also set in which case the toolchains configuration is still applied for toolchains-aware Maven plugins. As a result, checking and enforcing the Java version using the Apache Maven Enforcer Plugin will work.

To do this, create a file named .cloudmanager/java-version in the git repository branch used by the pipeline. This file can have either the content 11 or 8. Any other value is ignored. If 11 is specified, Oracle 11 is used and the JAVA_HOME environment variable is set to /usr/lib/jvm/jdk-11.0.22. If 8 is specified, Oracle 8 is used and the JAVA_HOME environment variable is set to /usr/lib/jvm/jdk1.8.0_401.

Environment Variables environment-variables

Standard Environment Variables standard-environ-variables

You may find it necessary to vary the build process based on information about the program or pipeline.

For example, if build-time JavaScript minification is being done through a tool like gulp, there may be a desire to use a different minification level when building for a development environment as opposed to building for staging and production.

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

Pipeline Variables pipeline-variables

Your build process may depend upon specific configuration variables which would be inappropriate to place in the git repository or you may need to vary them between pipeline executions using the same branch.

Please see the document Configuring Pipeline Variables for more information

Installing Additional System Packages installing-additional-system-packages

Some builds require additional system packages to be installed to function fully. For example, a build may invoke a Python or Ruby script and must have an appropriate language interpreter installed. This can be done 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.