JetBrains Space ヘルプ

ソースコードをチェックアウトする

ジョブはプロジェクトのソースコードを自動的にチェックアウトします。オートメーションスクリプトでこのステップを明示的に指定する必要はありません。デフォルトでは、チェックアウトされた Git リポジトリには、実際のリビジョン (現在実行中の .space.kts スクリプトが含まれるリビジョン) のみが含まれます。

プロジェクトのソースコードはどこに保存されますか

他のブランチおよびリビジョンをフェッチする

スクリプトが開始されると、オートメーションは実際のリポジトリリビジョン (現在実行中の .space.kts スクリプトを含むリポジトリリビジョン) のみをチェックアウトします。スクリプトの動作に他のブランチまたはリビジョンが必要な場合は、 git 項目を使用してフェッチできます。

例: main ブランチで実行されるスクリプトがあり、追加で release ブランチおよび git タグを取得したいとします。

job("Example") { git { // fetch 'release' and tags to local history refSpec { +"refs/heads/release" +"refs/tags/*:refs/tags/*" } // get the entire commit history depth = UNLIMITED_DEPTH } }

  • 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 があるとします。これは、これらの追加リポジトリをチェックアウトする方法です。

job("Example") { // check out repo-2 to /mnt/space/work/repo-2 git("repo-2") // check out repo-3 to /mnt/space/work/thirdRepo git("repo-3") { cloneDir = "thirdRepo" } container(displayName = "Show dirs", image = "amazoncorretto:17-alpine") { shellScript { content = """ echo Directory structure ls -R /mnt echo Working dir is pwd """ } } // Working dir is /mnt/space/work/main-repo }

  • 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 を使用します。

job("Example") { git("repo-2") { // fetch my-new-branch refSpec = "refs/heads/my-new-branch" // fetch the entire commit history depth = UNLIMITED_DEPTH } // Here go job steps... }

  • refSpec は、フェッチするリポジトリブランチまたはリビジョンをオートメーションに指示します。Git refspec(英語) マップ形式 (例: refSpec = "refs/*:refs/*") を使用し、正確なブランチ (例: refSpec = "refs/heads/my-new-branch") または正確なリビジョン (例: refSpec = "aa47aa1261b43732") を指定できます。

  • depth は、リポジトリのコミット履歴の深さ (最後のコミットの数) を指定します。UNLIMITED_DEPTH 値は、チェックアウトされたリポジトリにコミット履歴全体が含まれることを意味します。デフォルトの深さは 1 です。デフォルトでは、チェックアウトされたリポジトリには最新のコミットのみが含まれます。1 より大きい値は、フェッチする必要がある最後のコミットの正確な数を指定します。

他のプロジェクトのリポジトリをチェックアウトする

1 つのプロジェクトのオートメーションスクリプトは、Space の他のプロジェクトから Git リポジトリをチェックアウトできます。

  1. 必要な Git リポジトリを別のプロジェクトから現在のプロジェクトにアタッチします。詳細

  2. 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 環境変数を設定します。例:

job("Example") { git { // Do not download large files env["GIT_LFS_SKIP_SMUDGE"] = "1" } // here go job steps // ... }

オートメーションでは、Git 構成に Git 環境変数の一部 ( GIT_SSH_COMMAND など) も使用されることに注意してください。競合が発生した場合、job.git.env で提供される変数はデフォルトの変数をオーバーライドします。

ソースコードのチェックアウトを無効にする

ジョブがプロジェクトコードで動作することが想定されていない場合は、clone = false を設定することでプロジェクトソースのクローン作成を無効にすることができます。例:

job("Example") { git { clone = false } }

これにより、ジョブの実行時間が短縮されます。

ジョブ実行のトリガー 条件に応じてステップを実行する

関連ページ：

コンテナー

Space Automation を使用すると、Space Automation Cloud またはセルフホスト型ワーカー内の Docker コンテナーでジョブステップを実行できます。どのように機能するのか：コンテナーでステップを実行するには、ブロックを使用します。job(

セルフホスト型ワーカー

セルフホスト型ワーカーは、Windows、Linux、macOS 上の自分のマシンで実行できる軽量エージェントです。セルフホスト型ワーカーは、Space Automation に接続し、ジョブとプロジェクトソースコードを取得し、ジョブを実行して、結果を Space に報告します。セルフホスト型ワーカーを使用すると、コンテナーでは不可能な CI/CD ワークフローを実行できます。例:Windows 上で完全な .NET フレームワークアプリケーションを構築します。特定のハードウェアを使用します。例...

パッケージリポジトリの管理

システム管理者ロールを持つユーザーは、管理 | パッケージリポジトリページを使用してリポジトリのグローバル管理を実行できます。このページで利用できるリポジトリのリストは、ユーザーアカウントの権限によって異なります。管理 | パッケージリポジトリページで: アクティブには、プロジェクトにアタッチされているリポジトリのリストが表示されます。プロジェクト内にリポジトリを作成すると、そのリポジトリはこのプロジェクトにアタッチされます。接続されたリポジトリは、別名によって区別できます。リポジトリを複数のプロ...

リポジトリを別のプロジェクトに移動する

リポジトリをあるプロジェクトから別のプロジェクトに移動したり、リポジトリを別のプロジェクトにアタッチしたりすることで、両方のプロジェクトから同じリポジトリにアクセスして使用できるようになります。2 つの別々のプロジェクトにリポジトリを置くと、2 つの独立したチームで別々のコードレビューや課題追跡ワークフローを維持するのに役立つ場合があります。リポジトリは常に、そのままの形式で移動および接続されます。コードレビュー、コメント、課題はリポジトリと一緒にコピーされません。リポジトリが別のプロジェクト...

ジョブ実行のトリガー

自動化は次のジョブトリガーをサポートします。デフォルトで有効になっています。ユーザーが参照 (ブランチ、タグ、コミット、その他の Git 参照) をプロジェクトリポジトリにプッシュした後にジョブを実行します。の範囲を制限して、プロジェクトリポジトリ内の変更ではなく特定のブランチ、タグ、ディレクトリ、ファイルの変更についてのみがトリガーされるようにすることができます。マルチリポジトリプロジェクトがある場合は、特定のリポジトリ内の変更に対してジョブを実行するようにトリガーを設定できます。詳細 |DSL...