パスワードで保護された Maven リポジトリのサポート
パスワードで保護された Maven リポジトリのアーティファクトは、この方法でデプロイされるコードが Cloud Manager の品質ゲートによって適用される品質チェックに完全には従わないので、慎重に使用する必要があります。アドビでは、バイナリと共に Java ソースおよびプロジェクトのソースコード全体もデプロイすることをお勧めします。
Cloud Manager からのパスワードで保護された Maven リポジトリを使用するには、パスワード(および任意でユーザー名)を秘密のパイプライン変数として指定し、Git リポジトリの .cloudmanager/maven/settings.xml
という名前のファイル内でその秘密鍵を参照します。このファイルは、Maven 設定ファイルスキーマに従います。
Cloud Manager のビルドプロセスが開始すると、このファイル内の <servers>
要素が、Cloud Manager から提供されるデフォルトの settings.xml
ファイルに結合されます。カスタムサーバーでは、adobe
および cloud-manager
で始まるサーバー ID を使用しないでください。このような ID は予約済みと見なされます。Cloud Manager は、指定したプレフィックスの 1 つまたはデフォルトの ID central
に一致するサーバー ID のみをミラーリングします。
このファイルを配置すると、サーバー ID は pom.xml
ファイル内の <repository>
要素や <pluginRepository>
要素内から参照されます。一般に、これらの <repository>
要素や <pluginRepository>
要素は、Cloud Manager 固有のプロファイルに含まれていますが、厳密には必要ありません。
例えば、リポジトリが https://repository.myco.com/maven2
にあり、Cloud Manager が使用するユーザー名が cloudmanager
で、パスワードが secretword
だとします。
まず、パスワードをパイプライン上の秘密として設定します。
$ aio cloudmanager:set-pipeline-variables PIPELINEID --secret CUSTOM_MYCO_REPOSITORY_PASSWORD secretword
次に、.cloudmanager/maven/settings.xml
ファイルから次を参照します。
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://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>
最後に、pom.xml
ファイル内のサーバー ID を参照します。
<profiles>
<profile>
<id>cmBuild</id>
<activation>
<property>
<name>env.CM_BUILD</name>
</property>
</activation>
<build>
<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>
</build>
</profile>
</profiles>
ソースのデプロイ
バイナリと共に Java ソースを Maven リポジトリにデプロイすることをお勧めします。
プロジェクトで maven-source-plugin
を設定します。
<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>
プロジェクトソースのデプロイ
バイナリと共にプロジェクトソース全体を Maven リポジトリにデプロイすることをお勧めします。これにより、正確なアーティファクトを再ビルドできます。
プロジェクトで maven-assembly-plugin
を設定します。
<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>
コンテンツパッケージのスキップ
Cloud Manager では、ビルドは、任意の数のコンテンツパッケージを作成できます。
様々な理由により、コンテンツパッケージを生成してもデプロイしないことが望ましい場合があります。例えば、このアプローチは、テスト目的にのみにコンテンツパッケージをビルドする場合や、ビルドプロセスの別の手順でコンテンツパッケージを再パッケージ化する場合に役立ちます。つまり、別のパッケージのサブパッケージとして実行する場合に役立ちます。
これらのシナリオに対応するため、Cloud Manager はビルドコンテンツパッケージのプロパティで、cloudManagerTarget
という名前のプロパティを探します。このプロパティが none
に設定されている場合、パッケージはスキップされ、デプロイされません。このプロパティを設定する仕組みは、ビルドがコンテンツパッケージを作成する方法によって異なります。例えば、filevault-maven-plugin
でプラグインを設定する場合は、次のようになります。
<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
の場合は、次のようになります。
<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>
ビルドアーティファクトの再利用
多くの場合、同じコードが複数の AEM 環境にデプロイされます。Cloud Manager は、複数のフルスタックパイプライン実行で同じ Git コミットが使用されていることを検出した場合、コードベースの再ビルドを可能な限り避けます。
実行が開始されると、ブランチパイプラインの現在の HEAD コミットが抽出されます。コミットハッシュは、API を使用して UI に表示されます。ビルドステップが正常に完了すると、結果として生成されたアーティファクトはそのコミットハッシュに基づいて保存され、後続のパイプライン実行で再利用できます。
同じプログラム内にあるパッケージは、パイプラインをまたいで再利用されます。再利用可能なパッケージを探す際に、AEM はブランチを無視し、ブランチをまたいでアーティファクトを再利用します。
再利用が行われると、ビルドステップとコード品質ステップが元の実行の結果に事実上置き換えられます。ビルドステップのログファイルには、アーティファクトと、最初にアーティファクトのビルドに使用された実行情報が一覧表示されます。
そのようなログ出力の例を次に示します。
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)
コード品質ステップのログには、類似した情報が含まれます。
例
例 1
プログラムに 2 つの開発パイプラインがあるとします。
- ブランチ
foo
のパイプライン 1 - ブランチ
bar
のパイプライン 2
両方のブランチが同じコミット ID 上にあります。
- 最初にパイプライン 1 を実行すると、パッケージは通常どおりビルドされます。
- その後、パイプライン 2 を実行すると、パイプライン 1 で作成されたパッケージが再利用されます。
例 2
プログラムにはブランチ foo
とブランチ bar
という 2 つのブランチがあるとします。
両方のブランチのコミット ID が同じです。
- 開発パイプラインは、
foo
のビルドと実行を行います。 - その後、実稼動パイプラインが
bar
をビルドおよび実行します。
この場合、同じコミットハッシュが特定されたので、foo
のアーティファクトは実稼動パイプラインで再利用されます。