Erfahren Sie mehr über die spezielle Build-Umgebung, die Cloud Manager-Benutzer zum Erstellen und Testen Ihres Codes verwenden.
Die Build-Umgebungen von Cloud Manager weisen die folgenden Attribute auf.
/usr/lib/jvm/jdk1.8.0_371
/usr/lib/jvm/jdk-11.0.20
JAVA_HOME
auf /usr/lib/jvm/jdk1.8.0_371
festgelegt, was Oracle JDK 8u371 enthält. Weitere Einzelheiten finden Sie im Abschnitt Alternative JDK-Version für die Maven-Ausführung.bzip2
unzip
libpng
imagemagick
graphicsmagick
mvn --batch-mode org.apache.maven.plugins:maven-dependency-plugin:3.1.2:resolve-plugins
mvn --batch-mode org.apache.maven.plugins:maven-clean-plugin:3.1.0:clean -Dmaven.clean.failOnError=false
mvn --batch-mode org.jacoco:jacoco-maven-plugin:prepare-agent package
settings.xml
-Datei konfiguriert die automatisch das öffentliche Adobe-Artefakt-Repository enthält und ein Profil namens adobe-public
verwendet.
Obwohl Cloud Manager keine bestimmte Version des Programms des jacoco-maven-plugin
definiert, muss mindestens die Version 0.7.5.201505241946
verwendet werden.
In den folgenden zusätzlichen Ressourcen erfahren Sie, wie Sie Cloud Manager-APIs verwenden:
Standardmäßig werden Projekte vom Cloud Manager-Build-Prozess mit dem Oracle 8 JDK erstellt. Kunden, die ein alternatives JDK verwenden möchten, haben zwei Optionen.
Das Maven Toolchains-Plug-in ermöglicht es Projekten, ein bestimmtes JDK (oder Toolchain) auszuwählen, das im Kontext von Toolchain-fähigen Maven-Plug-ins verwendet werden soll. Dies geschieht in der pom.xml
-Datei 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>
Dies 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:
Anbieter | Version |
---|---|
Oracle | 1.8 |
Oracle | 1.11 |
Oracle | 11 |
Sun | 1.8 |
Sun | 1.11 |
Sun | 11 |
Ab April 2022 wird Oracle JDK das Standard-JDK für die Entwicklung und den Betrieb von AEM-Programmen sein. Der Build-Prozess von Cloud Manager wechselt automatisch zur Verwendung von Oracle JDK, auch wenn in der Maven-Toolchain explizit eine alternative Option ausgewählt ist. Weitere Informationen finden Sie in den Versionshinweisen vom April, sobald sie veröffentlicht werden.
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 Toolchain-Optionen ändert dies das für alle Plug-ins verwendete JDK, es sei denn, die Toolchain-Konfiguration ist ebenfalls festgelegt. In diesem Fall wird die Toolchain-Konfiguration weiterhin für Toolchain-fähige Maven-Plug-ins angewendet. Daher funktioniert in diesem Fall 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.2
festgelegt. Wenn 8
angegeben ist, wird Oracle 8 verwendet und die Umgebungsvariable JAVA_HOME
wird auf /usr/lib/jvm/jdk1.8.0_202
festgelegt.
In einigen Fällen muss der Build-Prozess je nach Informationen zum Programm oder zur Pipeline variiert werden.
Wenn beispielsweise eine JavaScript-Minimierung während der Build-Erstellung mithilfe eines Tools wie gulp durchgeführt wird, soll beim Erstellen für eine Entwicklungsumgebung möglicherweise eine andere Minimierungsstufe verwendet werden als beim Erstellen für eine Staging- oder Produktionsumgebung.
Um dies zu unterstützen, fügt Cloud Manager diese Standard-Umgebungsvariablen bei jeder Ausführung dem Build-Container hinzu.
Variablenname | Beschreibung |
---|---|
CM_BUILD |
Immer auf true (wahr) festgelegt |
BRANCH |
Die konfigurierte Verzweigung für die Ausführung |
CM_PIPELINE_ID |
Numerische Pipeline-Kennung |
CM_PIPELINE_NAME |
Name der Pipeline |
CM_PROGRAM_ID |
Numerische Programmkennung |
CM_PROGRAM_NAME |
Name des Programms |
ARTIFACTS_VERSION |
Die von Cloud Manager generierte synthetische Version bei einer Staging- oder Produktions-Pipeline |
Standard-Umgebungsvariablen können an verschiedenen Stellen verwendet werden.
In der Authoring-, Vorschau- und Veröffentlichungsumgebung können sowohl reguläre Umgebungsvariablen als auch Geheimnisse verwendet werden.
Im Dispatcher können nur reguläre Umgebungsvariablen verwendet werden. Geheimnisse können nicht verwendet werden.
Allerdings können Umgebungsvariablen nicht in IfDefine
-Richtlinien verwendet werden.
Sie sollten die Verwendung von Umgebungsvariablen lokal im Dispatcher validieren, bevor Sie sie bereitstellen.
In OSGi-Konfigurationen können sowohl reguläre Umgebungsvariablen als auch Geheimnisse verwendet werden.
In einigen Fällen kann der 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 in der pom.xml
-Datei 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.
_
) enthalten.
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>
Um vollständig zu funktionieren, benötigen einige Builds zusätzliche Systempakete, die installiert werden müssen. 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. Dies kann durch Abfrage von exec-maven-plugin
erfolgen, wodurch APT aufgerufen wird. Diese Ausführung sollte im Allgemeinen in einem Cloud Manager-spezifischen Maven-Profil eingeschlossen sein. So installieren Sie beispielsweise 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>
Mit derselben Methode können Sie auch sprachspezifische Pakete installieren, d. h. mit gem
für RubyGems oder mit pip
für Python-Pakete.
Wenn Sie ein Systempaket auf diese Weise installieren, wird es nicht in der Laufzeitumgebung installiert, die für die Ausführung von Adobe Experience Manager verwendet wird. Wenn Sie ein Systempaket in der AEM-Umgebung installieren möchten, wenden Sie sich an Ihre Adobe-Support-Mitarbeiter.