JetBrains Space Help

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

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:

  1. Checks out the project source code.

  2. Runs your custom shell script if you specified it in the warmup.script block.

  3. 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:

/ ├─── 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.

To view warm-up snapshots available in a project

  1. Open the project.

  2. In the sidebar, select Dev Environments.

  3. Switch to the Warm-up Snapshots tab.

To delete a warm-up snapshot

  1. Open the project.

  2. In the sidebar, select Dev Environments.

  3. Switch to the Warm-up Snapshots tab.

  4. Find the snapshot and click the Delete dev environment 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.

  1. Open the project.

  2. In the sidebar, select Dev Environments.

  3. Open the Warm-up Snapshots tab and select the required repository and branch.

  4. 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.

  5. 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.

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:

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

branchFilter supports the following filtering rules:

  • The filter supports the include and exclude 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:

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 and exclude 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 the tests directory. The src/tests/** matches all files inside tests and all its subdirectories.

  • A more specific path has priority over less specific paths, e.g. src/tests/MyTests.kt has priority over src/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'

Examples

Create indexes on schedule

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 * * *'

Build the project and create indexes on schedule

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'

Install IDE plugins, do not create indexes

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
Last modified: 04 March 2024