キャッシュファイル
ファイルキャッシュにより、ビルド時間が短縮され、リソースが節約される可能性があります。これは、プロジェクトの依存関係をローカルの Space ファイルリポジトリに保存することで機能します。こうすることで、同じビルドステップを再度実行するときに、参照されたパッケージをリモートサーバーからダウンロードするのではなく、キャッシュからすばやく取得できます。
デフォルトのキャッシュリポジトリ
Space のプロジェクトには、後続のジョブ実行用にキャッシュされたファイルを保存するためのデフォルトファイルリポジトリを関連付けることができます。
各プロジェクトには、対応するアクセス制限 (プロジェクトメンバーのみ) を備えたキャッシュ用の独自のデフォルトファイルリポジトリがあります。
リポジトリは、デフォルトのリポジトリを参照するジョブ (キャッシュされたファイルのアップロードなど) を初めて実行するときに自動的に作成されます。
スクリプトでは、
run:file-caches.default-repository
パラメーターからデフォルトのファイルリポジトリの名前を取得できます。デフォルトのファイルリポジトリを、Packages 内の他のファイルリポジトリに置き換えることができます。
デフォルトのリポジトリのデフォルト名は default-automation-caches です。この名前は、ファイルストレージ | キャッシュリポジトリのジョブ | 設定で変更できます。
デフォルトでは、デフォルトリポジトリにすでに存在するファイルをアップロードすると、そのファイルは上書きされます。詳細
デフォルトでは、キャッシュファイルは 7 日間アクセスされなかった場合に削除されます。デフォルトの保持ポリシーはリポジトリ設定で変更できます。
キャッシュされたファイルをアップロードして再利用する
ファイルキャッシュを操作するには、実行環境に応じて、job.container.cache
ブロックまたは job.host.cache
ブロックを使用します。例: npm プロジェクトの依存関係をキャッシュするには:
キャッシュの仕組み
デフォルトのキャッシュ location
は、デフォルトのキャッシュリポジトリ内の caches/{{ run:job.repository }}
ディレクトリです。デフォルトの場所がリポジトリレベルでどのように定義されているかに注意してください。デフォルトでは、同じリポジトリ内のすべてのジョブが同じキャッシュキーを再利用します。location
パラメーターを使用して、デフォルトの場所をオーバーライドできます。
ジョブの実行時に、オートメーションは {storeKey}.tar.gz
アーカイブがデフォルトの場所に存在するか、ユーザー指定の location
に存在するかを確認します。
ファイルが存在する場合、オートメーションは次のことを行います。
ファイルをダウンロードし、
localPath
に抽出します。スクリプトを実行します。
ファイルが存在しない場合、オートメーションは次のように処理します。
location
(またはデフォルトのリポジトリ) で、restoreKeys
で指定されたアーカイブを確認します。フォールバックキャッシュアーカイブが見つかった場合は、それを
localPath
に抽出し、スクリプトを実行します。フォールバックキャッシュアーカイブが見つからない場合、自動化は次のようにします。
スクリプトを実行します。
localPath
で指定されたディレクトリに .tar.gz アーカイブを作成します。オートメーションはファイル名としてstoreKey
文字列を使用します。.tar.gz アーカイブをデフォルトのキャッシュリポジトリまたは
location
で指定されたリポジトリにアップロードします。
アップロードパスとキャッシュキー名
location
を指定しない場合、オートメーションはキャッシュ .tar.gz アーカイブをデフォルトの default-automation-caches リポジトリの caches/{{ run:job.repository }}
ディレクトリにアップロードします。
キャッシュファイル名は、storeKey
パラメーター値 {storeKey}.tar.gz
によって定義されます。名前は一意である必要があり、必要なプロジェクトの依存関係によって明確に決定される必要があります。例: Node.js プロジェクトでは、依存関係は packages.json
ファイルで指定されているため、packages.json
の内容に基づいて storeKey
を生成するのは理にかなっています。このタスクの解決を支援するために、オートメーションでは hashFiles(files: Collection<String>): String
関数が提供されています。この関数は、ファイルの内容またはファイルの数に基づいてハッシュを生成します。関数を呼び出すには、パラメーター構文 (double 波括弧) を使用する必要があります。
例: storeKey = "npm-{{ hashFiles('package.json') }}"
または storeKey = "cache_{{ hashFiles('server/build.gradle.kts', 'client/build.gradle.kts') }}"
localPath の指定方法
localPath
は、キャッシュされるディレクトリの場所を定義します。次のように指定できます。
絶対パス (例:
/home/root/.m2
)。現在のホームディレクトリに対する相対パス (例:
~/.m2
)。job.host
ステップでのみ使用できます。詳細ステップの作業ディレクトリ (デフォルトでは、プロジェクトのルート) に対する相対パス (例:
node_modules
)。
リポジトリ間でキャッシュを共有する
デフォルトのキャッシュの場所は、リポジトリ名 caches/{{ run:job.repository }}
を含む相対パスを使用するため、Git リポジトリレベルで定義されます。
プロジェクト内の Git リポジトリ間でキャッシュを共有する場合は、location
パラメーターを使用してキャッシュへの絶対パスを指定します。例:
複数のディレクトリをキャッシュする
複数のディレクトリをキャッシュするには、複数のキャッシュルールを作成します。例:
デフォルトのマウントディレクトリの外にファイルをキャッシュする
job.host
を使用してセルフホストまたはクラウドマシンでステップを実行する場合は、必要なディレクトリへの絶対パスを指定するだけで済みます。例: localPath = "~/.m2/repository"
job.container
を使用してコンテナー内でステップを実行する場合は、状況が異なります。ここでは、マウントディレクトリ (デフォルトでは /mnt/space
) にあるファイルのみを参照できます。/mnt/space
の外部のディレクトリをキャッシュする場合は、デフォルトのマウントディレクトリを特定のホームディレクトリに変更する必要があります。CI/CD に使用されるコンテナーのほとんどは root ユーザーで実行されるため、これは root
ディレクトリになります。例:
フォールバックキャッシュ
オートメーションが {storeKey}.tar.gz
アーカイブを見つけられない場合は、restoreKeys
リストで指定されたファイルを探します。バージョンが比較的めったに変更されないプロジェクト全体の依存関係のこのようなフォールバックキャッシュを作成することをお勧めします。
ファイルリポジトリ内のキャッシュファイルを上書きする
Space のファイルリポジトリには不変ファイルオプションがあります。有効にすると、リポジトリは同じパスを持つファイルを複数回アップロードすることを禁止します。無効にすると、ファイルが上書きされる可能性があります。デフォルトでは、このオプションはデフォルトのファイルリポジトリに対して無効になっているため、ファイルが変更されると更新されます。
キャッシュをデフォルト以外のリポジトリにアップロードする
デフォルトとは異なるリポジトリにキャッシュをアップロードするには、cache.location
パラメーターを使用します。このリポジトリは、ジョブを実行するのと同じプロジェクトに属している必要があることに注意してください。
別のプロジェクトで作成されたファイルリポジトリにキャッシュをアップロードするには、まずこのリポジトリを現在のプロジェクトにアタッチする必要があります。
ファイル変更時のキャッシュアップロードを無効にする
多くのシナリオでは、変更されたファイルをキャッシュに再アップロードする必要はありません。例: JavaScript プロジェクトは、依存関係が変更されていない場合でも、各 npm install
の node_modules
ディレクトリ内のファイルを変更する可能性があります。
このような場合に不必要なキャッシュのアップロードを防ぐには、cache.reuploadWhenFilesChange
パラメーターを使用します。例:
プロジェクトのキャッシュファイルを表示する
目的のプロジェクトを開きます。
サイドバーメニューで、パッケージを選択します。
プロジェクトキャッシュを含むファイルリポジトリを開きます。デフォルトのファイルリポジトリの場合、default-automation-caches になります。
関連ページ:
ファイルアーティファクトを保存する
ビルドアーティファクトはビルドプロセスの出力です。たとえば、コードのコンパイルの結果として生成されたファイルなどです。オートメーションを使用して CI/CD パイプラインを構築すると、あるジョブ (CI/CD ステージ) によって作成されたファイルアーティファクトを別のジョブに渡すことができます。ファイルアーティファクトの作成がビルドプロセスの最終結果である場合は、このアーティファクトをファイルリポジトリに保存できます。デフォルトのアーティファクトリポジトリ:Space のプロジェクトには、ビ...
パッケージリポジトリの管理
システム管理者ロールを持つユーザーは、管理 | パッケージリポジトリページを使用してリポジトリのグローバル管理を実行できます。このページで利用できるリポジトリのリストは、ユーザーアカウントの権限によって異なります。管理 | パッケージリポジトリページで: アクティブには、プロジェクトにアタッチされているリポジトリのリストが表示されます。プロジェクト内にリポジトリを作成すると、そのリポジトリはこのプロジェクトにアタッチされます。接続されたリポジトリは、別名によって区別できます。リポジトリを複数のプロ...
セルフホスト型ワーカー
セルフホスト型ワーカーは、Windows、Linux、macOS 上の独自のマシンで実行できる軽量エージェントです。セルフホスト型ワーカーは Space Automation に接続し、ジョブとプロジェクトのソースコードを取得してジョブを実行し、結果を Space にレポートします。セルフホスト型ワーカーを使用すると、コンテナーでは不可能な CI/CD ワークフローを実行できます。例:Windows 上で完全な .NET フレームワークアプリケーションを構築します。特定のハードウェアを使用する...
プロジェクトに参加する
あるプロジェクトに貢献を開始したい場合は、そのプロジェクトに参加する必要があります。つまり、そのプロジェクトのメンバーになる必要があります。貢献しようとしているプロジェクトに移動します。すでにメンバーである場合は、プロジェクトのページのプロジェクトメンバーにリストされます。そうでない場合は、プロジェクト管理者に連絡してメンバーシップを依頼してください。プロジェクト管理者を確認するには、プロジェクトページでメンバーウィジェットをクリックします。プロジェクトを探す:すべてのプロジェクトは名前で見つ
デプロイ
デプロイは、ソースコードの変更を Space からデプロイ環境 (オートメーションの観点からはデプロイターゲット) に配信します。例: Space を使用して Web アプリケーションを開発します。環境はステージングサーバーと運用サーバーで構成されます。これらのサーバーはデプロイターゲットです。新しいアプリケーションバージョンを特定のサーバーに配信するプロセスはデプロイです。デプロイの主なゴールは、製品のリリースライフサイクルをより透明にすることです。デプロイターゲット (Web、デスクトップ、...