Warm-up
Dev environments can significantly increase the speed of development by removing the IDE warm-up phase: a period of time when the IDE builds indexes, and does other background activities like resolving project dependencies. You can put all these routines into a dev environment warm-up and run it on schedule or on commit push. The result of the warm-up is a warm-up snapshot (a Docker volume) that is then mounted to a dev environment. Make sure the warm-up is run regularly: The fresher the index data is, the faster a dev environment will be ready for work.
To configure warm-up, use the warmup
parameter. For example:
How the warm-up works
When the warm-up is triggered, Space creates a run environment based on the devfile settings: the specified container image, environment variables, and so on. In this warmup environment, Space:
Checks out the project source code.
Runs your custom shell script if you specified it in the
warmup.script
block.Builds project indexes for the IDE specified in the devfile.
Project indexes are specific for each IDE and most often for each IDE version. For the warm-up, Space uses the IDE version specified in the
editor.version
parameter of the devfile. If the version is not specified, the warm-up will create indexes for the default IDE version.If you don't want the warm-up to build project indexes, specify:
warmup: indexing: false
Warm-up snapshot
Technically, a warm-up snapshot is a Docker volume that contains the /root
(the container always runs under the root
user) and /mnt/space
directories:
Everything outside these directories is discarded. For this reason you should not use the warm-up, for example, to install additional tools with apt get
. For this purpose, use custom dev environment images.
Space stores only the latest warm-up snapshot for each combination of an IDE and a Git branch. An IDE version is not taken into account. For example, a project has two branches: main
and feature-branch
. Suppose some developers use JetBrains Fleet and some use IntelliJ IDEA. There can be four snapshots maximum: main
+ Fleet, main
+ IDEA, feature-branch
+ Fleet, and feature-branch
+ IDEA.
Important notes:
Storing warm-up snapshots is included in disk storage billing. Learn more about billing
Dev environments started from the same snapshot are independent of each other and do not share their state in any way.
To view warm-up snapshots available in a project
In the sidebar, select Dev Environments.
Switch to the Warm-up Snapshots tab.
To delete a warm-up snapshot
In the sidebar, select Dev Environments.
Switch to the Warm-up Snapshots tab.
Find the snapshot and click the Delete button.
Trigger the warm-up
By default, warm-up triggers are disabled for a project. To enable the triggers, open project settings, and on the Dev Environments tab, enable warm-up triggering for the required project repository.
There are three ways to trigger the warm-up: manually in the Space UI, by schedule, and by pushing a commit to the project repository.
In the sidebar, select Dev Environments.
Open the Warm-up Snapshots tab and select the required repository and branch.
Click Run warm-up for {your-defvile}. If the project has more than one devfile, click Show all detected devfiles and Run warm-up for the required devfile.
You can check the warm-up execution state on the project's Dev Environments page.
The schedule
trigger runs the warm-up in the default project branch (which is main
by default). The schedule
warm-up triggers specified in other branches don't trigger the warm-up.
In schedule
, use the UTC timezone and the crontab format (MIN HOUR DAY MONTH DAYOFWEEK):
The gitPush
trigger runs the warm-up after a user pushes a commit to the project repository.
You can limit the scope of gitPush
so that it triggers not on any change in the project repository but only on changes in particular branches, tags, directories, or files.
Filter by branch
By default, when a commit is pushed to the repository, Space tries to run the warm-up from the devfile.yaml
file in the same branch where the changes were committed. For example, if you push changes to the cool-feature
branch, Space will try running the warm-up from the devfile.yaml
file in this revision in the cool-feature
branch.
branchFilter
lets you specify the list of branches where Space should run the warm-up. For example, the following warm-up will run only on changes in the my-feature
branch:
If a change is pushed to the my-feature
branch, this warm-up will start in the my-feature
but not in the main
or any other branch. If a change is pushed to the main
branch, none of the warm-ups will start – Space will try to run the script in the main
branch, but it has the branchFilter
that prevents this.
branchFilter
supports the following filtering rules:
The filter supports the
include
andexclude
rules.You can use asterisk (
*
) wildcards, e.g.include: - 'refs/heads/release-*'The filter supports include and exclude rules for regular expressions, e.g.
includeRegex: - 'release-\d+' excludeRegex: - 'release-221'Exclude rules have priority over include rules.
branchFilter
also lets you specify filters by Git tags, e.g.# run only if there's a release tag # e.g., release/v1.0.0 include: - 'refs/tags/release/*'For example:
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'
Filter by path
pathFilter
lets you specify paths to certain directories and files. For example, the warm-up below will run only if there is a change in the Main.kt
file:
You can use pathFilter
to fine-tune branchFilter
: Space first checks if there's a change in a particular branch and only then it applies a pathFilter
. If branchFilter
is not specified, pathFilter
works only within the current branch (the one with the committed changes).
pathFilter
supports the following filtering rules:
The warm-up will run if at least one file matches the specified filter.
The filter supports the
include
andexclude
rules.You should specify path relative to the project root directory.
You can use asterisk (
*
) wildcards for matching the files only inside the current directory and double-asterisk (**
) for a recursive match. For example,src/tests/*
matches all files inside thetests
directory. Thesrc/tests/**
matches all files insidetests
and all its subdirectories.A more specific path has priority over less specific paths, e.g.
src/tests/MyTests.kt
has priority oversrc/tests/**
.For example:
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'