Die Build-Umgebung build-environment

Erfahren Sie mehr über die spezielle Build-Umgebung, die Cloud Manager-Benutzer zum Erstellen und Testen Ihres Codes verwenden.

Umgebungsdetails details

Cloud Manager-Build-Umgebungen weisen die folgenden Attribute auf.

HTTPS-Maven-Repositorys https-maven

Cloud Manager 2023.10.0 hat eine rollierende Aktualisierung der Build-Umgebung gestartet (abgeschlossen mit Version 2023.12.0), die eine Aktualisierung auf Maven 3.8.8 enthielt. Eine wesentliche Änderung, die in Maven 3.8.1 eingeführt wurde, war eine Sicherheitsverbesserung, die darauf abzielte, potenzielle Schwachstellen zu minimieren. Insbesondere deaktiviert Maven jetzt standardmäßig alle unsicheren http://* Spiegel, wie in den Maven-Versionshinweisen beschrieben.

Aufgrund dieser Sicherheitsverbesserung können bei einzelnen Benutzenden während des Build-Schritts Probleme auftreten, insbesondere beim Herunterladen von Artefakten aus Maven-Repositorys, die unsichere HTTP-Verbindungen verwenden.

Um ein reibungsloses Erlebnis mit der aktualisierten Version zu gewährleisten, empfiehlt Adobe, dass Benutzende ihre Maven-Repositorys so aktualisieren, dass sie HTTPS anstelle von HTTP verwenden. Diese Anpassung steht im Einklang mit dem wachsenden Trend der Branche hin zu sicheren Kommunikationsprotokollen und trägt zur Aufrechterhaltung eines sicheren und zuverlässigen Build-Prozesses bei.

Verwenden einer bestimmten Java-Version using-java-version

Standardmäßig verwenden vom Cloud Manager-Build-Prozess erstellte Projekte das Oracle 8 JDK. Kunden, die ein alternatives JDK verwenden möchten, haben zwei Optionen.

Maven Toolchains maven-toolchains

Mit dem Maven Toolchain-Plug-in können Projekte ein bestimmtes JDK (oder eine Toolchain) auswählen, das im Kontext von toolchain-basierten Maven-Plug-ins verwendet werden soll. Dieser Vorgang erfolgt in der Datei "pom.xml" des Projekts, indem ein Anbieter und ein Versionswert angegeben werden. Ein Beispielabschnitt in der Datei pom.xml ist:

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

Dieser Vorgang führt dazu, dass alle Toolchain-fähigen Maven-Plug-ins das Oracle JDK, Version 11 verwenden.

Bei Verwendung dieser Methode wird Maven selbst weiterhin mit dem standardmäßigen JDK (Oracle 8) ausgeführt und die JAVA_HOME-Umgebungsvariable wird nicht geändert. Daher funktioniert das Überprüfen oder Erzwingen der Java-Version über Plug-ins wie das Apache Maven Enforcer-Plug-in nicht und solche Plug-ins dürfen nicht verwendet werden.

Die derzeit verfügbaren Anbieter-/Versionskombinationen sind:

JDK-Version der alternativen Maven-Ausführung alternate-maven

Es ist auch möglich, Oracle 8 oder Oracle 11 als JDK für die gesamte Maven-Ausführung auszuwählen. Im Gegensatz zu den Optionen der Toolketten ändert dies das JDK, das für alle Plug-ins verwendet wird, es sei denn, die Konfiguration der Toolketten ist ebenfalls festgelegt. In diesem Fall wird die Konfiguration der Toolketten weiterhin für die Maven-Plug-ins angewendet, die für Toolketten verwendet werden. Daher funktioniert das Überprüfen und Erzwingen der Java-Version mit dem Apache Maven Enforcer-Plug-in.

Erstellen Sie dazu eine Datei mit dem Namen .cloudmanager/java-version in der von der Pipeline verwendeten Git-Repository-Verzweigung. Diese Datei kann entweder den Inhalt 11 oder 8 enthalten. Alle anderen Werte werden ignoriert. Wenn 11 angegeben ist, wird Oracle 11 verwendet und die Umgebungsvariable JAVA_HOME wird auf /usr/lib/jvm/jdk-11.0.22 festgelegt. Wenn 8 angegeben ist, wird Oracle 8 verwendet und die Umgebungsvariable JAVA_HOME wird auf /usr/lib/jvm/jdk1.8.0_401 festgelegt.

Umgebungsvariablen environment-variables

Standard-Umgebungsvariablen standard-environ-variables

In einigen Fällen muss der Build-Prozess je nach Informationen zum Programm oder zur Pipeline variiert werden.

Wenn Sie beispielsweise ein Tool wie gulp für die JavaScript-Minimierung verwenden, bevorzugen Sie möglicherweise unterschiedliche Minimierungsstufen für Entwicklungs-, Staging- und Produktionsumgebungen.

Um dies zu unterstützen, fügt Cloud Manager diese Standard-Umgebungsvariablen bei jeder Ausführung dem Build-Container hinzu.

Verfügbarkeit der Standard-Umgebungsvariablen availability

Standard-Umgebungsvariablen können an verschiedenen Stellen verwendet werden.

Autoren-, Vorschau- und Veröffentlichungsumgebungen author-preview-publish

In der Authoring-, Vorschau- und Veröffentlichungsumgebung können sowohl reguläre Umgebungsvariablen als auch Geheimnisse verwendet werden.

Dispatcher dispatcher

Nur normale Umgebungsvariablen können mit der Dispatcher verwendet werden. Geheimnisse können nicht verwendet werden.

Umgebungsvariablen können jedoch nicht in IfDefine -Direktiven verwendet werden.

OSGi-Konfigurationen osgi

In den OSGi-Konfigurationen können sowohl reguläre Umgebungsvariablen als auch Geheimnisse verwendet werden.

Pipeline-Variablen pipeline-variables

In einigen Fällen kann Ihr Build-Prozess von bestimmten Konfigurationsvariablen abhängen, die nicht im Git-Repository platziert werden können oder zwischen Pipeline-Ausführungen mit derselben Verzweigung variieren müssen.

Cloud Manager ermöglicht die Konfiguration dieser Variablen über die Cloud Manager-API oder die Cloud Manager-CLI individuell für die Pipelines. Variablen können entweder als reiner Test oder mit Data-at-Rest-Verschlüsselung gespeichert werden. In beiden Fällen werden Variablen innerhalb der Build-Umgebung als Umgebungsvariable bereitgestellt, die dann aus der Datei pom.xml oder anderen Build-Skripten referenziert werden kann.

Um eine Variable mithilfe der CLI festzulegen, führen Sie einen Befehl ähnlich dem folgenden aus.

$ aio cloudmanager:set-pipeline-variables PIPELINEID --variable MY_CUSTOM_VARIABLE test

Aktuelle Variablen können mit einem Befehl ähnlich dem folgenden aufgelistet werden.

$ aio cloudmanager:list-pipeline-variables PIPELINEID

Variablen müssen bestimmte Einschränkungen einhalten.

Bei Verwendung in einer Maven-pom.xml-Datei ist es in der Regel hilfreich, diese Variablen Maven-Eigenschaften mithilfe einer ähnlichen Syntax wie der folgenden zuzuordnen.

        <profile>
            <id>cmBuild</id>
            <activation>
                <property>
                    <name>env.CM_BUILD</name>
                </property>
            </activation>
            <properties>
                <my.custom.property>${env.MY_CUSTOM_VARIABLE}</my.custom.property>
            </properties>
        </profile>

Installieren zusätzlicher Systempakete installing-additional-system-packages

Damit einige Builds vollständig funktionieren, müssen zusätzliche Systempakete installiert werden. So ist es z. B. möglich, dass ein Build ein Python- oder Ruby-Skript aufruft, wofür der entsprechende Sprach-Interpreter installiert sein muss. Dieses Szenario kann durch Aufruf von exec-maven-plugin zum Aufrufen von APT durchgeführt werden. Diese Ausführung sollte im Allgemeinen in einem Cloud Manager-spezifischen Maven-Profil eingeschlossen sein. Um beispielsweise Python zu installieren, können Sie Folgendes tun:

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

Diese Technik kann auch verwendet werden, um sprachspezifische Pakete zu installieren. Verwenden Sie also gem für RubyGems oder pip für Python-Pakete.