ウォームアップ
開発環境では、IDE ウォームアップフェーズ (IDE がインデックスを構築し、プロジェクトの依存関係の解決などのその他のバックグラウンドアクティビティを実行する期間) を削除することで、開発速度を大幅に向上させることができます。これらすべてのルーチンを開発環境のウォームアップに配置し、スケジュールまたはコミットプッシュで実行できます。ウォームアップの結果、ウォームアップスナップショット (Docker ボリューム) が作成され、開発環境にマウントされます。ウォームアップが定期的に実行されていることを確認してください。インデックスデータが新鮮であればあるほど、開発環境の作業準備が整います。
ウォームアップを設定するには、warmup
パラメーターを使用します。例:
ウォームアップの仕組み
ウォームアップがトリガーされると、Space は devfile 設定 (指定されたコンテナーイメージ、環境変数など) に基づいて実行環境を作成します。このウォームアップ環境では、Space は次のようになります。
プロジェクトのソースコードをチェックアウトします。
warmup.script
ブロックでカスタムシェルスクリプトを指定した場合、それを実行します。devfile で指定された IDE のプロジェクトインデックスを構築します。
プロジェクトインデックスは各 IDE に固有であり、ほとんどの場合、各 IDE バージョンに固有です。ウォームアップのために、Space は devfile の
editor.version
パラメーターで指定された IDE バージョンを使用します。バージョンが指定されていない場合、ウォームアップではデフォルトの IDE バージョンのインデックスが作成されます。ウォームアップでプロジェクトインデックスを構築したくない場合は、次のように指定します。
warmup: indexing: false
ウォームアップのスナップショット
技術的には、ウォームアップスナップショットは、/root
(コンテナーは常に root
ユーザーで実行されます) および /mnt/space
ディレクトリを含む Docker ボリュームです。
これらのディレクトリの外側にあるものはすべて破棄されます。このため、たとえば apt get
で追加のツールをインストールするためにウォームアップを使用しないでください。この目的のために、カスタム開発環境イメージを使用します。
Space には、IDE と Git ブランチの組み合わせごとに最新のウォームアップスナップショットのみが保存されます。IDE のバージョンは考慮されません。例: プロジェクトには main
と feature-branch
という 2 つのブランチがあります。一部の開発者は JetBrains Fleet を使用し、一部の開発者は IntelliJ IDEA を使用するとします。スナップショットは最大 4 つあります: main
+ Fleet、main
+ IDEA、feature-branch
+ Fleet、および feature-branch
+ IDEA。
重要なメモ:
ウォームアップスナップショットの保存は、ディスクストレージの料金に含まれています。請求について詳しくはこちら
同じスナップショットから開始された開発環境は互いに独立しており、状態をまったく共有しません。
プロジェクトで使用可能なウォームアップスナップショットを表示するには
サイドバーで、開発環境を選択します。
ウォームアップスナップショットタブに切り替えます。
ウォームアップスナップショットを削除するには
サイドバーで、開発環境を選択します。
ウォームアップスナップショットタブに切り替えます。
スナップショットを見つけて、「
削除」ボタンをクリックします。
ウォームアップを開始する
デフォルトでは、プロジェクトのウォームアップトリガーは無効になっています。トリガーを有効にするには、プロジェクト設定を開き、開発環境タブで必要なプロジェクトリポジトリのウォームアップトリガーを有効にします。
ウォームアップをトリガーするには、Space UI で手動で行う方法、スケジュールに従って行う方法、プロジェクトリポジトリにコミットをプッシュする方法の 3 つの方法があります。
サイドバーで、開発環境を選択します。
ウォームアップスナップショットタブを開き、必要なリポジトリとブランチを選択します。
{your-defvil} のウォームアップを実行しますをクリックします。プロジェクトに複数の devfile がある場合は、必要な devfile の検出されたすべての devfile を表示およびウォーミングアップを実行するをクリックします。
ウォームアップの実行状態はプロジェクトの開発環境ページで確認できます。
schedule
トリガーは、デフォルトプロジェクトブランチ (デフォルトでは main
) でウォームアップを実行します。他のブランチで指定されている schedule
ウォームアップトリガーはウォームアップをトリガーしません。
schedule
では、UTC タイムゾーンと crontab 形式 (MIN HOUR DAY MONTH DAYOFWEEK) を使用します。
gitPush
トリガーは、ユーザーがプロジェクトリポジトリにコミットをプッシュした後、ウォームアップを実行します。
プロジェクトリポジトリ内の変更ではなく、特定のブランチ、タグ、ディレクトリ、ファイルの変更のみをトリガーするように、gitPush
の範囲を制限できます。
ブランチでフィルター
デフォルトでは、コミットがリポジトリにプッシュされると、Space は変更がコミットされたのと同じブランチ内の devfile.yaml
ファイルからウォームアップを実行しようとします。例: cool-feature
ブランチに変更をプッシュすると、Space は cool-feature
ブランチでこのリビジョンの devfile.yaml
ファイルからウォームアップを実行しようとします。
branchFilter
を使用すると、Space がウォームアップを実行する必要があるブランチのリストを指定できます。例: 次のウォームアップは、my-feature
ブランチの変更時にのみ実行されます。
変更が my-feature
ブランチにプッシュされた場合、このウォームアップは my-feature
で開始されますが、main
やその他のブランチでは開始されません。変更が main
ブランチにプッシュされた場合、ウォームアップは開始されません。Space は main
ブランチでスクリプトを実行しようとしますが、これを阻止する branchFilter
があります。

branchFilter
は次のフィルタリングルールをサポートしています。
フィルターは、
include
ルールとexclude
ルールをサポートします。アスタリスク (
*
) ワイルドカードを使用できます。include: - 'refs/heads/release-*'フィルターは、正規表現の包含ルールと除外ルールをサポートします。
includeRegex: - 'release-\d+' excludeRegex: - 'release-221'除外ルールは、含めるルールよりも優先されます。
branchFilter
では、Git タグによってフィルターを指定することもできます。# run only if there's a release tag # e.g., release/v1.0.0 include: - 'refs/tags/release/*'例:
schemaVersion: 2.2.0 attributes: space: editor: type: Idea warmup: startOn: - type: gitPush branchFilter: # add 'main' and all '222.*' tags include: - 'refs/heads/main' - 'refs/tags/222.*' # add all branches containing 'feature' includeRegex: - 'feature' # exclude test-feature exclude: - 'refs/heads/test-feature'
パスによるフィルター
pathFilter
を使用すると、特定のディレクトリおよびファイルへのパスを指定できます。例: 以下のウォームアップは、Main.kt
ファイルに変更があった場合にのみ実行されます。
pathFilter
を使用して branchFilter
を微調整できます。Space は最初に特定のブランチに変更があるかどうかを確認し、その後で初めて pathFilter
を適用します。branchFilter
が指定されていない場合、pathFilter
は現在のブランチ (変更がコミットされたもの) 内でのみ機能します。
pathFilter
は次のフィルタリングルールをサポートしています。
少なくとも 1 つのファイルが指定されたフィルターに一致する場合、ウォームアップが実行されます。
フィルターは、
include
ルールとexclude
ルールをサポートします。プロジェクトのルートディレクトリを基準とした相対パスを指定する必要があります。
現在のディレクトリ内のみでファイルを照合するにはアスタリスク (
*
) ワイルドカードを使用し、再帰的照合には二重アスタリスク (**
) を使用できます。例:src/tests/*
は、tests
ディレクトリ内のすべてのファイルと一致します。src/tests/**
は、tests
内のすべてのファイルとそのすべてのサブディレクトリに一致します。より具体的なパスは、それほど具体的ではないパスよりも優先されます。
src/tests/MyTests.kt
はsrc/tests/**
よりも優先されます。例:
schemaVersion: 2.2.0 attributes: space: editor: type: Idea warmup: startOn: - type: gitPush branchFilter: include: - 'refs/heads/main' pathFilter: exclude: # exclude 'targets/main' dir - 'targets/main/**' include: # include everything from 'targets' dir - 'targets/**' # include all 'Main.kt' files in the project # As this rule is more specific, # 'Main.kt' will be included even if # it's located in 'targets/main' - '**/Main.kt' # include all '.java' files from the 'common' dir - 'common/**/*.java'
サンプル
スケジュールに従ってインデックスを作成する
プロジェクトをビルドし、スケジュールに従ってインデックスを作成する
IDE プラグインをインストールします。インデックスは作成しません
関連ページ:

IDE
devfile を使用すると、開発環境で使用する IDE、JVM オプション (IntelliJ ベースの IDE の場合)、およびプロジェクトルートディレクトリを指定できます。デフォルトの IDE を指定する:開発環境では、JetBrains の IDE Fleet、IntelliJ IDEA、WebStorm、PyCharm、RubyMine、CLion、GoLand、PhpStorm、Rider* を使用できます。利用可能な IDE に関する情報を取得するために、Space は JetBrai...

実行環境
実行環境は、開発環境インスタンスに使用される Docker イメージ、インスタンス型、およびインスタンスに提供される環境変数のセットのパラメーターによって定義されます。デフォルトの Docker イメージ:Docker イメージを指定しない場合、Space はデフォルトのイメージを使用します。デフォルトのイメージは Ubuntu OS に基づいており、Git、curl、Docker、Docker Compose、Kubernetes、Google Cloud サポート、Open JDK、Pyth...

プロジェクトに参加する
あるプロジェクトに貢献を開始したい場合は、そのプロジェクトに参加する必要があります。つまり、そのプロジェクトのメンバーになる必要があります。貢献しようとしているプロジェクトに移動します。すでにメンバーである場合は、プロジェクトのページのプロジェクトメンバーにリストされます。そうでない場合は、プロジェクト管理者に連絡してメンバーシップを依頼してください。プロジェクト管理者を確認するには、プロジェクトページでメンバーウィジェットをクリックします。プロジェクトを探す:すべてのプロジェクトは名前で見つ

パラメーターとシークレット
devfile を使用すると、プロジェクトおよび個人のパラメーターとシークレットを開発環境に提供できます。開発環境内では、これらのパラメーターとシークレットを環境変数として参照できます。プロジェクトのパラメーターとシークレットを開発環境に提供する:開発環境には、プロジェクト全体に共通のパラメーターとシークレット (URL、ファイルパス、共通認証トークンなど) を提供できます。必要なプロジェクトパラメーターとシークレットを定義するには、プロジェクトの devfile を使用します。開発環境は、プロジ...