ソースコードをチェックアウトする
ジョブはプロジェクトのソースコードを自動的にチェックアウトします。オートメーションスクリプトでこのステップを明示的に指定する必要はありません。デフォルトでは、チェックアウトされた Git リポジトリには、実際のリビジョン (現在実行中の .space.kts
スクリプトが含まれるリビジョン) のみが含まれます。
プロジェクトのソースコードはどこに保存されますか
ジョブの実行時に、オートメーションは Git リポジトリをホストマシン上の作業ディレクトリ
.../work/{git-repo-name}
にチェックアウトします。ここで、{git-repo-name}
はプロジェクトの Git リポジトリ名です。作業ディレクトリの正確な場所は、ホストマシンの環境によって異なります。以下のリンクをクリックして情報を入手してください
JB_SPACE_WORK_DIR_PATH
環境変数を使用すると、作業ディレクトリへの絶対パスをいつでも取得できます。自動化は、現在のリポジトリリビジョン (現在実行中の
.space.kts
ファイルを含むリポジトリリビジョン) のみをチェックアウトします。必要に応じて、このリポジトリから他のブランチおよびリビジョンをフェッチすることもできます。マルチリポジトリプロジェクトがある場合、オートメーションスクリプトは追加のプロジェクトリポジトリをチェックアウトできます。
スクリプトで Space 内の他のプロジェクトの Git リポジトリが必要な場合は、それらもチェックアウトできます。
他のブランチおよびリビジョンをフェッチする
スクリプトが開始されると、オートメーションは実際のリポジトリリビジョン (現在実行中の .space.kts
スクリプトを含むリポジトリリビジョン) のみをチェックアウトします。スクリプトの動作に他のブランチまたはリビジョンが必要な場合は、 git
項目を使用してフェッチできます。
例: main
ブランチで実行されるスクリプトがあり、追加で release
ブランチおよび git タグを取得したいとします。
refSpec
は、フェッチするリポジトリブランチまたはリビジョンをオートメーションに指示します。Git refSpec(英語) マップ形式 (たとえば、refSpec = "refs/*:refs/*"
) を使用して、正確なブランチ (たとえば、refSpec = "refs/heads/my-new-branch"
) または正確なリビジョン (たとえば、refSpec = "aa47aa1261b43732"
) を指定できます。depth
は、リポジトリのコミット履歴の深さ (最後のコミットの数) を指定します。UNLIMITED_DEPTH
値は、チェックアウトされたリポジトリにコミット履歴全体が含まれることを意味します。デフォルトの深さは1
です。デフォルトでは、チェックアウトされたリポジトリには最新のコミットのみが含まれます。1
より大きい値は、フェッチする必要がある最後のコミットの正確な数を指定します。
プロジェクト内の他のリポジトリをチェックアウトする
プロジェクトに複数の Git リポジトリが含まれており、オートメーションスクリプトの実行中にこれらのリポジトリが必要な場合、これらのリポジトリもチェックアウトできます。これを行うには、 git
アイテムを使用します。
プロジェクトに、.space.kts
ファイルを含む main-repo
リポジトリと、ビルド中に必要な他の 2 つのリポジトリ repo-2
および repo-3
があるとします。これは、これらの追加リポジトリをチェックアウトする方法です。
git(...)
は、メインプロジェクトリポジトリ (現在実行中の.space.kts
スクリプトファイルを含むリポジトリ) だけでなく、プロジェクトから別の Git リポジトリもチェックアウトしたいことをオートメーションに指示します。git
項目はjob
レベルで指定されることに注意してください。これは、このジョブ内で実行されているすべてのコンテナーが追加の Git リポジトリを取得することを意味します。cloneDir
は、チェックアウトディレクトリを指定します。絶対パスまたは/mnt/space/work
からの相対パスのいずれかです。デフォルトでは、チェックアウトディレクトリは/mnt/space/work/${repo-name}
です。この例では、
/mnt/space/work
ディレクトリには 3 つのサブディレクトリが含まれます。/mnt/space/work/main-repo
とメインリポジトリ (現在実行中の.space.kts
が含まれるリポジトリ) のコンテンツ。/mnt/space/work/repo-2
とrepo-2
の内容。/mnt/space/work/thirdRepo
とrepo-3
の内容。
作業ディレクトリは
/mnt/space/work/main-repo
です。
追加リポジトリのチェックアウトルール
オートメーションは、実行中のスクリプトが属しているブランチと同じ名前のブランチをチェックアウトしようとします。例:
main-repo
とrepo-2
という 2 つのリポジトリがあります。どちらにも 2 つのブランチ (main
およびmy-feature
) があります。main-repo/my-feature
でスクリプトを実行すると、ジョブはrepo-2
(最新リビジョン) からmy-feature
ブランチをチェックアウトします。main-repo/main
でジョブを実行すると、repo-2/main
がチェックアウトされます。同じ名前のブランチが追加リポジトリに見つからない場合、ジョブは
main
ブランチをチェックアウトします。例:main-repo
とmain
およびmy-feature
ブランチ、およびrepo-2
とmain
ブランチの 2 つのリポジトリがあるとします。main-repo/my-feature
でスクリプトを実行すると、ジョブはrepo-2
(最終リビジョン) からmain
ブランチをチェックアウトします。
追加のリポジトリのコンテンツを取得する
他のブランチまたは追加リポジトリのリビジョンをフェッチするには、refSpec
を使用します。
refSpec
は、フェッチするリポジトリブランチまたはリビジョンをオートメーションに指示します。Git refspec(英語) マップ形式 (例:refSpec = "refs/*:refs/*"
) を使用し、正確なブランチ (例:refSpec = "refs/heads/my-new-branch"
) または正確なリビジョン (例:refSpec = "aa47aa1261b43732"
) を指定できます。depth
は、リポジトリのコミット履歴の深さ (最後のコミットの数) を指定します。UNLIMITED_DEPTH
値は、チェックアウトされたリポジトリにコミット履歴全体が含まれることを意味します。デフォルトの深さは1
です。デフォルトでは、チェックアウトされたリポジトリには最新のコミットのみが含まれます。1
より大きい値は、フェッチする必要がある最後のコミットの正確な数を指定します。
他のプロジェクトのリポジトリをチェックアウトする
1 つのプロジェクトのオートメーションスクリプトは、Space の他のプロジェクトから Git リポジトリをチェックアウトできます。
必要な Git リポジトリを別のプロジェクトから現在のプロジェクトにアタッチします。詳細
git
アイテムを使用して、ジョブで必要なリポジトリを参照します。接続されたリポジトリは、プロジェクト内の他のリポジトリと同様に操作できます ( 前の章で説明したとおり)。job("Example") { // repo-from-another-project must be attached to the current project git("repo-from-another-project") container(displayName = "Run script", image = "ubuntu") { // here goes your script } }
環境変数を使用して Git チェックアウトを構成する
場合によっては、Git がプロジェクトソースをチェックアウトする方法を変更する必要があるかもしれません。例: ビルドに特定の大きなファイルが必要ない場合は、Git LFS スマッジ (大きなファイルを実際のコンテンツに置き換える) を無効にすることができます。
Git チェックアウトを構成するには、job.git.env
を使用して Git 環境変数を設定します。例:
オートメーションでは、Git 構成に Git 環境変数の一部 ( GIT_SSH_COMMAND
など) も使用されることに注意してください。競合が発生した場合、job.git.env
で提供される変数はデフォルトの変数をオーバーライドします。
ソースコードのチェックアウトを無効にする
ジョブがプロジェクトコードで動作することが想定されていない場合は、clone = false
を設定することでプロジェクトソースのクローン作成を無効にすることができます。例:
これにより、ジョブの実行時間が短縮されます。
関連ページ:
![](https://pleiades.io/icons/jetbrains_logo.png)
コンテナー
Space Automation を使用すると、Space Automation Cloud またはセルフホスト型ワーカー内の Docker コンテナーでジョブステップを実行できます。どのように機能するのか:コンテナーでステップを実行するには、ブロックを使用します。job("Example"){ // displayName is optional // it will be shown in the job run results container(displayName = "Say H...
![](https://resources.jetbrains.com/help/img/space/externalWorkerTags.png)
セルフホスト型ワーカー
セルフホスト型ワーカーは、Windows、Linux、macOS 上の独自のマシンで実行できる軽量エージェントです。セルフホスト型ワーカーは Space Automation に接続し、ジョブとプロジェクトのソースコードを取得してジョブを実行し、結果を Space にレポートします。セルフホスト型ワーカーを使用すると、コンテナーでは不可能な CI/CD ワークフローを実行できます。例:Windows 上で完全な .NET フレームワークアプリケーションを構築します。特定のハードウェアを使用する...
![](https://resources.jetbrains.com/help/img/space/package_repositories_admin.png)
パッケージリポジトリの管理
システム管理者ロールを持つユーザーは、管理 | パッケージリポジトリページを使用してリポジトリのグローバル管理を実行できます。このページで利用できるリポジトリのリストは、ユーザーアカウントの権限によって異なります。管理 | パッケージリポジトリページで: アクティブには、プロジェクトにアタッチされているリポジトリのリストが表示されます。プロジェクト内にリポジトリを作成すると、そのリポジトリはこのプロジェクトにアタッチされます。接続されたリポジトリは、別名によって区別できます。リポジトリを複数のプロ...
![](https://resources.jetbrains.com/help/img/space/chooseRepositoryAdministration.png)
リポジトリを別のプロジェクトに移動する
リポジトリをあるプロジェクトから別のプロジェクトに移動したり、リポジトリを別のプロジェクトにアタッチしたりすることで、両方のプロジェクトから同じリポジトリにアクセスして使用できるようになります。2 つの別々のプロジェクトにリポジトリを置くと、2 つの独立したチームで別々のコードレビューや課題追跡ワークフローを維持するのに役立つ場合があります。リポジトリは常に、そのままの形式で移動および接続されます。コードレビュー、コメント、課題はリポジトリと一緒にコピーされません。リポジトリが別のプロジェクト...
![](https://resources.jetbrains.com/help/img/space/gitPush-singleRepo-branchFilter.png)
ジョブ実行のトリガー
自動化は次のジョブトリガーをサポートします。デフォルトで有効になっています。ユーザーが参照 (ブランチ、タグ、コミット、その他の Git 参照) をプロジェクトリポジトリにプッシュした後にジョブを実行します。の範囲を制限して、プロジェクトリポジトリ内の変更ではなく特定のブランチ、タグ、ディレクトリ、ファイルの変更についてのみがトリガーされるようにすることができます。マルチリポジトリプロジェクトがある場合は、特定のリポジトリ内の変更に対してジョブを実行するようにトリガーを設定できます。詳細 |DSL...