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:
schemaVersion: 2.2.0
attributes:
space:
instanceType: regular
editor:
type: Idea
version: '2022.1'
# The resulting warm-up snapshot will contain
# project indexes for IDEA 2022.1 and
# data created by './gradlew assemble' and './scripts/warmup.sh'.
# The warmup will run in the 'my-devenv-container' specified below.
warmup:
# The warm-up will run on git push to the main branch
# and on schedule - every Sunday (UTC)
startOn:
- type: schedule
cron: '0 0 0 ? * SUN *'
- type: gitPush
branchFilter:
include:
- 'refs/heads/main'
script: |
./gradlew assemble
./scripts/warmup.sh
components:
- name: my-devenv-container
container:
image: mycompany.registry.jetbrains.space/p/myprj/container/dev-image:latest
note
(Deprecated) Running the warm-up in an Automation job
Before devfiles, the only way to configure the warm-up was to use an Automation script (the
.space.kts
file). In this case, the warm-up runs as a regular Automation job. This way of configuring the warm-up is no longer possible – you can still use the snapshots created by such jobs, but the jobs won't run.
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
warning
Project indexing is in the beta state and might not work in some specific cases.
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:
/
├─── root // user directory with project indexes (saved during the warm-up or hibernation)
│...
├─── mnt
│ └─── space // saved during the warm-up or hibernation
│ ├─── system // non-user system files
│ └─── work
│ └─── {git-repo-name} // cloned git repository (working directory)
...
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.
In the sidebar, select Dev Environments.
Switch to the Warm-up Snapshots tab.
In the sidebar, select Dev Environments.
Switch to the Warm-up Snapshots tab.
Find the snapshot and click the
Delete button.
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):
schemaVersion: 2.2.0
attributes:
space:
instanceType: regular
editor:
type: WebStorm
version: '2022.1'
warmup:
# run warm-up every Friday at 23:59 UTC
startOn:
- type: schedule
cron: '59 23 * * FRI'
The gitPush
trigger runs the warm-up after a user pushes a commit to the project repository.
schemaVersion: 2.2.0
attributes:
space:
instanceType: regular
editor:
type: WebStorm
version: '2022.1'
warmup:
# run warm-up on every push to the project repo
startOn:
- type: gitPush
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.
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:
schemaVersion: 2.2.0
attributes:
space:
editor:
type: Idea
warmup:
startOn:
- type: gitPush
branchFilter:
include:
- 'refs/heads/my-feature'
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.
![Run a warmup on gitPush with branchFilter Run a warmup on gitPush with branchFilter](https://resources.jetbrains.com/help/img/space/gitPush-warmup-branchFilter-runInBranch.png)
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'
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:
schemaVersion: 2.2.0
attributes:
space:
editor:
type: Idea
warmup:
startOn:
- type: gitPush
pathFilter:
# Main.kt is in the project root
include:
- 'Main.kt'
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'
schemaVersion: 2.2.0
metadata:
name: 'Latest Idea release (only indexing)'
attributes:
space:
editor:
type: Idea
warmup:
# run every day at 4:00 and 12:00
startOn:
- type: schedule
cron: '0 4,12 * * *'
schemaVersion: 2.2.0
metadata:
name: 'Latest Idea release (build and indexing)'
attributes:
space:
editor:
type: Idea
warmup:
# run every day at 4:00 and 12:00
startOn:
- type: schedule
cron: '0 4,12 * * *'
# run the build script
script: './build.sh'
schemaVersion: 2.2.0
metadata:
name: 'Latest Idea release (only plugins)'
attributes:
space:
editor:
type: Idea
warmup:
# do not create indexes
indexing: false
# install plugins
script: |
/mnt/space/system/ide/bin/remote-dev-server.sh installPlugins . \
org.rust.lang \
com.intellij.bigdatatools \
another.plugin.id
Thanks for your feedback!