Attivazione dei profili Maven in Cloud Manager
In alcuni casi limitati, potrebbe essere necessario modificare leggermente il processo di build durante l’esecuzione in Cloud Manager rispetto a quando viene eseguito dalle workstation di sviluppo. Per questi casi è possibile utilizzare i profili Maven per definire il modo in cui la build deve differire nei diversi ambienti, incluso Cloud Manager.
L’attivazione di un profilo Maven all’interno dell’ambiente di build di Cloud Manager deve essere eseguita cercando la CM_BUILD
variabile di ambiente. Analogamente, per un profilo destinato a essere utilizzato esclusivamente al di fuori dell’ambiente di build di Cloud Manager, è necessario verificare l’assenza di tale variabile.
Ad esempio, se desideri inviare un messaggio semplice solo quando la build viene eseguita in Cloud Manager, effettua la seguente operazione:
<profile>
<id>cmBuild</id>
<activation>
<property>
<name>env.CM_BUILD</name>
</property>
</activation>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>initialize</phase>
<configuration>
<target>
<echo>I'm running inside Cloud Manager!</echo>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
-PcmBuild
) o nell’ambiente di sviluppo integrato (IDE).E se desideri inviare un messaggio semplice solo quando la build viene eseguita al di fuori di Cloud Manager, effettua le seguenti operazioni:
<profile>
<id>notCMBuild</id>
<activation>
<property>
<name>!env.CM_BUILD</name>
</property>
</activation>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>initialize</phase>
<configuration>
<target>
<echo>I'm running outside Cloud Manager!</echo>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
Utilizzare un archivio Maven protetto da password in Cloud Manager
Per utilizzare un archivio Maven protetto da password in Cloud Manager:
- Specifica la password (e facoltativamente il nome utente) come variabile segreta della pipeline.
- Fai riferimento al segreto all’interno del file denominato
.cloudmanager/maven/settings.xml
nell’archivio Git, che segue lo schema del file delle impostazioni Maven.
All’avvio del processo di build di Cloud Manager:
-
L’elemento
<servers>
in questo file viene unito al file predefinitosettings.xml
fornito da Cloud Manager.- Gli ID server che iniziano con
adobe
ecloud-manager
sono considerati riservati. Non utilizzarli su server personalizzati. - Cloud Manager esegue il mirroring solo degli ID server che corrispondono a prefissi specifici o all'ID predefinito
central
; tutti gli altri ID server sono esclusi dal mirroring.
- Gli ID server che iniziano con
-
Quando questo file è presente, si fa riferimento all’ID server da un
<repository>
e/o da un elemento del<pluginRepository>
contenuto nel filepom.xml
. -
In genere, questi elementi
<repository>
e<pluginRepository>
sono inclusi in un profilo specifico di Cloud Manager, anche se la loro inclusione non è strettamente richiesta.
Supponiamo ad esempio che l’archivio si trovi nella posizione https://repository.myco.com/maven2
e che il nome utente che Cloud Manager debba utilizzare sia cloudmanager
, con password secretword
. Effettua le seguenti operazioni:
-
Imposta la password come segreto nella pipeline.
$ aio cloudmanager:set-pipeline-variables PIPELINEID --secret CUSTOM_MYCO_REPOSITORY_PASSWORD secretword`
-
Fai riferimento a questo segreto dal file
.cloudmanager/maven/settings.xml
nel seguente:<?xml version="1.0" encoding="UTF-8"?> <settings xmlns="https://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd"> <servers> <server> <id>myco-repository</id> <username>cloudmanager</username> <password>${env.CUSTOM_MYCO_REPOSITORY_PASSWORD}</password> </server> </servers> </settings>
-
Infine, fai riferimento all’ID server nel file
pom.xml
:<profiles> <profile> <id>cmBuild</id> <activation> <property> <name>env.CM_BUILD</name> </property> </activation> <repositories> <repository> <id>myco-repository</id> <name>MyCo Releases</name> <url>https://repository.myco.com/maven2</url> <snapshots> <enabled>false</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>myco-repository</id> <name>MyCo Releases</name> <url>https://repository.myco.com/maven2</url> <snapshots> <enabled>false</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </pluginRepository> </pluginRepositories> </profile> </profiles>
Distribuire le origini
È buona prassi distribuire le origini Java insieme ai dati binari in un archivio Maven.
Per farlo, configura il plug-in maven-source nel progetto.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
Distribuzione delle origini del progetto
È buona prassi distribuire l’intera origine del progetto insieme ai dati binari in un archivio Maven. In questo modo è possibile ricostruire l’artefatto esatto.
Configura il maven-assembly-plugin nel progetto nel modo seguente:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>project-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptorRefs>
<descriptorRef>project</descriptorRef>
</descriptorRefs>
</configuration>
</execution>
</executions>
</plugin>
Ignorare i pacchetti di contenuti
In Cloud Manager le build possono produrre qualsiasi numero di pacchetti di contenuti. Per diversi motivi può essere utile produrre un pacchetto di contenuti ma non distribuirlo. Un esempio si verifica quando i pacchetti di contenuti vengono generati solo a scopo di test o quando un altro passaggio del processo di build li ricompila. ovvero un pacchetto secondario di un altro pacchetto.
Per soddisfare questi scenari, Cloud Manager cerca una proprietà denominata cloudManagerTarget
tra le proprietà dei pacchetti di contenuto della build. Se questa proprietà è impostata su none
, il pacchetto viene ignorato e non distribuito.
Il meccanismo per impostare questa proprietà dipende dal modo in cui la build produce il pacchetto di contenuti. Ad esempio, con filevault-maven-plugin
è possibile configurare il plug-in come indicato di seguito.
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<properties>
<cloudManagerTarget>none</cloudManagerTarget>
</properties>
<!-- other configuration -->
</configuration>
</plugin>
content-package-maven-plugin
presenta una configurazione analoga.
<plugin>
<groupId>com.day.jcr.vault</groupId>
<artifactId>content-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<properties>
<cloudManagerTarget>none</cloudManagerTarget>
</properties>
<!-- other configuration -->
</configuration>
</plugin>
Riutilizzo degli artefatti di generazione
In molti casi, lo stesso codice viene distribuito in più ambienti AEM. Quando possibile, Cloud Manager evita di ricostruire la base di codice quando rileva che lo stesso commit Git viene utilizzato in più esecuzioni di pipeline full-stack.
All’avvio di un’esecuzione, viene estratto il commit HEAD corrente per la pipeline del ramo. L’hash del commit è visibile nell’interfaccia utente e tramite l’API. Al termine della fase di build, gli artefatti risultanti vengono archiviati in base a tale hash di commit e possono essere riutilizzati nelle esecuzioni successive della pipeline.
Se si trovano nello stesso programma, i pacchetti vengono riutilizzati tra le pipeline. Durante la ricerca di pacchetti da poter riutilizzare, AEM ignora i rami e riutilizza gli artefatti tra rami.
In caso di un riutilizzo, i passaggi di build e qualità del codice vengono effettivamente sostituiti con i risultati dell’esecuzione originale. Il file di registro per il passaggio di build elenca gli artefatti e le informazioni di esecuzione utilizzate per generarli originariamente.
Di seguito è riportato un esempio di tale output del registro.
The following build artifacts were reused from the prior execution 4 of pipeline 1 which used commit f6ac5e6943ba8bce8804086241ba28bd94909aef:
build/aem-guides-wknd.all-2021.1216.1101633.0000884042.zip (content-package)
build/aem-guides-wknd.dispatcher.cloud-2021.1216.1101633.0000884042.zip (dispatcher-configuration)
Il log del passaggio di qualità del codice conterrà informazioni simili.
Esempi
Esempio 1
Ipotizza di utilizzare un programma con due pipeline di sviluppo:
- Pipeline 1 su ramo
foo
- Pipeline 2 su ramo
bar
Entrambi i rami presentano lo stesso ID commit.
- L’esecuzione della pipeline 1 genera i pacchetti normalmente.
- Quindi, l’esecuzione della pipeline 2 riutilizza i pacchetti creati dalla pipeline 1.
Esempio 2
Ipotizza di utilizzare un programma con due rami:
- Ramo
foo
- Ramo
bar
Entrambi i rami presentano lo stesso ID commit.
- Una pipeline di sviluppo genera ed esegue
foo
. - Successivamente viene creata ed eseguita una pipeline di produzione
bar
.
In questo caso, l’artefatto da foo
viene riutilizzato per la pipeline di produzione poiché è stato identificato lo stesso hash del commit.
Disattivazione
Se lo desideri, puoi disattivare il comportamento di riutilizzo per specifiche pipeline impostando la variabile di pipeline CM_DISABLE_BUILD_REUSE
su true
. Se questa variabile è impostata, il sistema estrae l’hash di commit e memorizza gli artefatti risultanti per un uso successivo, ma non riutilizza gli artefatti archiviati in precedenza. Per comprendere questo comportamento, considera lo scenario seguente:
- Viene creata una nuova pipeline.
- La pipeline viene eseguita (esecuzione n. 1) e il commit HEAD corrente è
becdddb
. L’esecuzione ha esito positivo e gli artefatti risultanti vengono archiviati. - Viene impostata la variabile
CM_DISABLE_BUILD_REUSE
. - La pipeline viene rieseguita senza modificare il codice. Anche se sono presenti artefatti archiviati associati a
becdddb
, non vengono riutilizzati per via della variabileCM_DISABLE_BUILD_REUSE
. - Il codice viene modificato e la pipeline eseguita. Il commit HEAD ora è
f6ac5e6
. L’esecuzione ha esito positivo e gli artefatti risultanti vengono archiviati. - La variabile
CM_DISABLE_BUILD_REUSE
viene eliminata. - La pipeline viene rieseguita senza modificare il codice. Poiché sono presenti artefatti archiviati associati a
f6ac5e6
, questi artefatti vengono riutilizzati.