JetBrains Space Help

Configure Dev Environment for Project

To provide the best possible experience, a dev environment must be pre-configured for your project. A configured environment includes all necessary tools and runtimes, IDE indexes, and other data required by the project, e.g., environment variables, project dependencies, and so on. As a result, a user can start working on their project right after a dev environment is created.

Configuration steps

Dev environment configuration includes the following steps (you can skip any of these steps depending on your needs):

  1. Specify a configuration name

  2. Specify a dev environment instance type

    Dev environments come in three different types that differ by available compute resources.

  3. Specify a default IDE

    You can specify a default IDE and a particular IDE version for the project.

  4. Specify a container image

    The image must include the tooling and runtimes required by the project. You can use an image from Docker Hub (or other registries that doesn't require authentication), from a Space Packages registry, or even define a custom image using a Dockerfile file in the project repository.

    If you skip this step, the created dev environments will use the default image.

  5. Create a warm-up snapshot

    A warm-up snapshot contains pre-built project data. By default, the snapshot contains only IDE indexes, but it can also contain additional project data like dependencies, build caches, and so on. You can automate creating a warm-up snapshot: Space can create it on schedule or on commit push.

    If you skip this step, Space will create dev environments without warm-up data.

  6. Set environment variables

    Define environment variables that are required for development in a dev environment.

  7. Specify user secrets and parameters required for development

    A dev environment might require sensitive user data, e.g. credentials to an external service. User secrets and parameters are available in a dev environment as environment variables.

  8. Configure JVM options for IntelliJ-based IDEs

    You can change the configuration of Java Virtual Machine (JVM) your IntelliJ-based IDE runs on.

  9. Specify the project root directory

Default dev environment

Configuring a dev environment is optional. If you skip it, Space will use a default dev environment: the environment based on the default Docker image with no additional project data.

The default Docker image is based on Ubuntu OS and includes Git, curl, Docker, Docker Compose, Kubernetes, Google Cloud support, Open JDK, Python, PHP, .NET SDK, Ruby, Go, Node.js, npm, yarn, and other tools.

Default image Dockerfile:

FROM ubuntu:20.04 ENV LANG=C.UTF-8 MAINTAINER Alexander Sedov <alexander.sedov@jetbrains.com> ARG TARGETARCH # Support various rvm, nvm etc stuff which requires executing profile scripts (-l) SHELL ["/bin/bash", "-lc"] CMD ["/bin/bash", "-l"] # Set debconf to run non-interactively RUN echo 'debconf debconf/frontend select Noninteractive' | debconf-set-selections RUN apt-get update && apt-get install -y apt-utils apt-transport-https software-properties-common # Newest git RUN apt-add-repository ppa:git-core/ppa -y && apt-get update RUN set -ex -o pipefail && apt-get install -y \ # Useful utilities \ curl unzip wget socat man-db rsync moreutils vim lsof \ # VCS \ git subversion subversion-tools mercurial \ # Database clients \ mongodb-clients mysql-client postgresql-client jq redis-tools \ # C/C++ \ build-essential cmake g++ m4 \ # R \ r-base r-base-dev \ # TeX \ texlive \ # JVM \ openjdk-8-jre-headless openjdk-11-jdk-headless openjdk-17-jdk-headless maven ant clojure scala \ # Python 3 \ python3-matplotlib python3-numpy python3-pip python3-scipy python3-pandas python3-dev pipenv \ # Python 2 \ python2-dev python-pip-whl \ # Ruby \ ruby-full \ && \ # Setup Java \ update-alternatives --get-selections | grep usr/lib/jvm | awk '{print $1}' | \ grep -v jpackage | grep -v jexec | \ while IFS= read line; do echo $line; update-alternatives --set $line /usr/lib/jvm/java-11-openjdk-$TARGETARCH/bin/$line; done && \ java -version && javac -version && \ # Check Python \ python3 --version && python2 --version && pip3 --version && \ # Go \ curl -fsSL "https://dl.google.com/go/$(curl -fsSL 'https://golang.org/VERSION?m=text').linux-$TARGETARCH.tar.gz" -o /tmp/go.tar.gz && \ tar -C /usr/local -xzf /tmp/go.tar.gz && rm /tmp/go.tar.gz && \ for x in /usr/local/go/bin/*; do echo $x; ln -vs $x /usr/local/bin/$(basename $x); done && ls -la /usr/local/bin && go version ## Nodejs, npm, yarn RUN set -ex -o pipefail && \ curl -fsSL https://deb.nodesource.com/setup_16.x | bash - && \ curl -fsSL https://dl.yarnpkg.com/debian/pubkey.gpg | gpg --dearmor | tee /usr/share/keyrings/yarnkey.gpg >/dev/null && \ echo "deb [signed-by=/usr/share/keyrings/yarnkey.gpg] https://dl.yarnpkg.com/debian stable main" | tee /etc/apt/sources.list.d/yarn.list && \ apt-get update && apt-get install -y nodejs yarn ## PHP RUN set -ex -o pipefail && \ add-apt-repository ppa:ondrej/php -y && \ apt-get install -y --no-install-recommends php8.0-cli php8.0-common php8.0-curl php8.0-xml php8.0-mbstring && \ wget https://github.com/composer/composer/releases/download/2.2.1/composer.phar -O /usr/bin/composer -q && \ chmod +x /usr/bin/composer ## dotNet RUN if [ "$TARGETARCH" == "arm64" ] ; \ then echo "Skipping installation of .NET packages, as they are only available for arm64 starting from Ubuntu 22.04" ; \ else set -ex -o pipefail && \ wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb && \ dpkg -i packages-microsoft-prod.deb && \ rm packages-microsoft-prod.deb && \ apt-get update && \ apt-get install -y dotnet-sdk-6.0 ; \ fi ### Cloud Tools ## The awscli tools use a different naming scheme for arm64 builds RUN if [ "$TARGETARCH" == "arm64" ] ; \ then AWS_TOOLS_ARCH=aarch64 ; \ else AWS_TOOLS_ARCH=x86_64 ; \ fi && \ set -ex -o pipefail && \ # Docker \ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg && \ echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list && \ apt-get install -y docker.io && \ docker --version && \ # Kubernetes \ curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg && \ echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | tee /etc/apt/sources.list.d/kubernetes.list && \ apt-get update && apt-get install -y kubectl && \ kubectl version --client && \ # aws-cli \ curl -fsSL "https://awscli.amazonaws.com/awscli-exe-linux-$AWS_TOOLS_ARCH.zip" -o /tmp/awscliv2.zip && \ mkdir -p /tmp/aws.extracted && \ unzip -q /tmp/awscliv2.zip -d /tmp/aws.extracted && \ /tmp/aws.extracted/aws/install && \ rm -rf /tmp/aws.extracted /tmp/awscliv2.zip && \ /usr/local/bin/aws --version && \ # gcloud \ curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key --keyring /usr/share/keyrings/cloud.google.gpg add - && \ echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | tee /etc/apt/sources.list.d/google-cloud-sdk.list && \ apt-get update && apt-get install -y google-cloud-sdk && \ gcloud --version && \ # rclone \ curl -fsSL https://downloads.rclone.org/v1.56.2/rclone-v1.56.2-linux-$TARGETARCH.zip -o /tmp/rclone.zip && \ mkdir -p /tmp/rclone.extracted && unzip -q /tmp/rclone.zip -d /tmp/rclone.extraced && \ install -g root -o root -m 0755 -v /tmp/rclone.extraced/*/rclone /usr/local/bin && \ rm -rf /tmp/rclone.extraced /tmp/rclone.zip && \ rclone --version ## Docker compose (https://docs.docker.com/compose/install/) ## There are no arm64 builds of docker-compose for version 1.x.x, so version 2.x.x is used RUN if [ "$TARGETARCH" == "arm64" ] ; \ then DOCKER_COMPOSE_VERSION=v2.14.0 ; \ else DOCKER_COMPOSE_VERSION=1.29.2 ; \ fi && \ set -ex -o pipefail && \ curl -fsSL "https://github.com/docker/compose/releases/download/$DOCKER_COMPOSE_VERSION/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose && \ chmod +x /usr/local/bin/docker-compose && \ rm -f /usr/bin/docker-compose && \ ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose RUN echo "############################### Versions #####################################" && \ java -version && \ javac -version && \ echo "" && \ python3 --version && \ python2 --version && \ pip3 --version && \ echo "" && \ go version && \ echo "" && \ echo ".NET SDK" && \ if [ "$TARGETARCH" != "arm64" ] ; then dotnet --list-sdks ; else echo "Not available for arm64" ; fi && \ echo "" && \ echo ".NET Runtimes" && \ if [ "$TARGETARCH" != "arm64" ] ; then dotnet --list-runtimes ; else echo "Not available for arm64" ; fi && \ echo "" && \ echo "Nodejs: $(node --version)" && \ echo "Npm: $(npm --version)" && \ echo "Yarn: $(yarn --version)" && \ echo "" && \ ruby --version && \ echo "" && \ php -v && \ composer -V && \ echo "" && \ docker --version && \ docker-compose --version && \ echo "" && \ echo "Kubectl: $(kubectl version --client)" && \ echo "" && \ gcloud --version && \ echo "" && \ rclone --version && \ echo "############################### Versions #####################################"

You can use this Dockerfile as a basis for creating your own image and hosting it in Space Packages. Learn more

Devfile configuration file

To configure a dev environment for a project, you should use a devfile. Devfile is an open specification that uses YAML formatting for configuring and running build environments. Currently, Space supports only a feature subset of the 2.2.0 specification (the supported features are fully covered by the documentation topic you're currently reading).

A project may have a single devfile.yaml file or a number of *.devfile.yaml files located in the .space directory in the repository root. When users create a dev environment, they can choose from all devfiles available in the project. Dev environment settings are taken from the selected devfile.

Choose a devfile

Here's an example of a devfile.yaml file:

schemaVersion: 2.2.0 metadata: name: 'My custom dev env configuration' attributes: space: # regular, large, xlarge instanceType: large # a default IDE for the project editor: # (Required) IDE type: Idea, WebStorm, PyCharm, # RubyMine, CLion, Fleet, GoLand, PhpStorm type: Idea version: '2022.1' # Space uses JetBrains Toolbox App to install IDEs to a dev environment. # updateChannel defines IDE version release stage: Release, EAP updateChannel: EAP # JVM configuration (appends to the default .vmoptions file) vmoptions: - '-Xms2048m' - '-Xmx4096m' # a warm-up snapshot warmup: # create a snapshot every Sunday (only for main branch) startOn: - type: schedule cron: '0 0 0 ? * SUN *' # run additional warmup script (IDE indexes will be built anyway) script: ./scripts/warmup.sh # Parameters and secretes required by a dev environment # e.g., credentials to an external service requiredParameters: # (Required) the name of the environment variable # that will be available in the dev environment - name: USERNAME description: 'Space username' requiredSecrets: - name: PASSWORD description: 'Space permanent token' components: - name: dev-container # Dev environment container config container: # use image from a Space Packages registry image: mycompany.registry.jetbrains.space/p/myprj/container/my-dev-image:27 # environment variables env: - name: API_URL value: 'https://my-site/http_api' - name: PATH_IMG value: './img/'

Specify a configuration name

To help users distinguish a partcular dev environment configuration in a project with several devfiles, specify a name for each configuration. If you don't specify a name, the configuration will be named after the IDE it uses.

To specify the name, use the metadata.name parameter:

schemaVersion: 2.2.0 metadata: name: 'My custom config' attributes: space: editor: type: Idea

Users will see this name when selecting a devfile for a newly created dev environment.

Config name

Specify a default dev environment instance type

Dev environments can run on three different virtual machine instances: regular (4 vCPUs, 8 GB), large (8 vCPUs, 16 GB), and extra large (16 vCPUs, 32 GB). Learn more about dev environments billing.

To specify a default instance type, use the space.instanceType parameter. Users can choose another instance type when creating a dev environment.

schemaVersion: 2.2.0 attributes: space: # regular, large, xlarge instanceType: large editor: type: Idea

Specify a default IDE

You can use the following IDEs from JetBrains in a dev environment: Fleet, IntelliJ IDEA, WebStorm, PyCharm, RubyMine, CLion, GoLand, PhpStorm, and Rider *. To get information about available IDEs, Space uses the JetBrains Toolbox App update service. You can view the available IDEs, IDE versions, and version release states (e.g., Release, EAP, and so on) on the dev environments administration page.

Using the space.editor parameters, you can specify a default IDE, IDE version, and version release state. Users can change any of these settings when creating a dev environment. When warming up a dev environment, Space will build IDE indexes for the IDE and IDE version specified in the devfile.

schemaVersion: 2.2.0 attributes: space: editor: # (Required) IDE type: Idea, WebStorm, PyCharm, # RubyMine, CLion, Fleet, GoLand, PhpStorm, Rider type: WebStorm version: '2022.1' # release state, e.g. Release or EAP updateChannel: Release

Default IDE version

If not specified in a devfile, the default IDE version is always the latest available release version. This is the organization-wide default. To change it, a user must have the Edit dev environments settings global permission (for example, this can be an administrator with the System Admin role).

To specify the default IDE version for organization dev environments

  1. Open Administration, then Dev Environments.

  2. Under Default IDE versions, find the required IDE and choose a new default version.

    Default IDE

Use JetBrains Rider in a dev environment

If you want to use a dev environment with JetBrains Rider, you must additionaly specify a path to the solution file. To specify the path, use the projectRoot parameter. For example:

schemaVersion: 2.2.0 attributes: space: editor: type: Rider version: '2022.1' # projectRoot is specified # relative to repository root projectRoot: projects/my-project/MySolution.sln

Specify an image for the dev environment

A dev environment runs in a Docker container. If you don't specify an image in a devfile.yaml, Space will use the default image. As a custom image, you can use an image from Docker Hub (or other registries that doesn't require authentication), Space Packages, or create an image from Dockerfile each time a user creates a new dev environment. To specify the image, use the project's devfile.

Image requirements
  • OS: any glibc-based Linux distribution (for example, CentOS 7+, Debian 9+, Ubuntu 20.04+).

  • Tools: Git, OpenSSH (if you want to use a remote Git repository), lsof (if you need port forwarding in the IDE).

  • The container must run as root (there must be no non-root users in Dockerfile).

Container image vs warm-up snapshot

In some cases, you might face a dilemma where to put a certain preparation step: to the container image or to the environment warm-up. For example, your project requires an SDK. To get the SDK, you run curl - o sdk.zip $SDK_URL && unzip sdk.zip. Where do you put this line: to the Dockerfile or to the warm-up script?

Our recommendation is to use the Dockerfile only to configure the environment. All binary dependencies should go to a warm-up script. So, in the example above, the best solution would be to get the SDK in a warm-up script.

In the components.container.image parameter, specify the full image URL.

Important: the Space Packages registry must either belong to the same project where you configure a dev environment or be attached to this project.

schemaVersion: 2.2.0 attributes: space: instanceType: regular editor: type: Idea components: - name: ubuntu-container container: image: mycompany.registry.jetbrains.space/p/myprj/container/dev-image:latest

A dev environment can use a custom Dockerfile for its container image. The Dockerfile can be located anywhere in the project repository. Note that in this case, Space will build the image each time a user creates a new dev environment. To reduce startup time of the dev environment, we recommend that you build the image once and publish it to the project's Space Packages registry.

  1. Open the project source code and create a Dockerfile, for example, in the docker directory.

  2. Edit the Dockerfile to configure the image.

    For example, an image for a Java project:

    FROM ubuntu:20.04 ENV DEBIAN_FRONTEND=noninteractive ENV LC_ALL=C.UTF-8 RUN apt-get update RUN apt-get install -y \ git \ openjdk-11-jdk \ && rm -rf /var/lib/apt/lists/* ENV JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
  3. Open the project source code and open the project's devfile. If it doesn't exist, create a new one, for example, .space/devfile.yaml.

  4. In the devfile, specify the path to a Dockerfile (uri) and, optionally, to the Docker context (buildContext). You must specify both paths relative to the projectRoot. For example:

    schemaVersion: 2.2.0 attributes: space: instanceType: large editor: type: Idea components: - name: image-build image: # (Required) imageName: my-image:latest dockerfile: # (Optional) path to Docker context relative to projectRoot # by default, projectRoot is repository root buildContext: docker # (Required) path to Dockerfile relative to projectRoot uri: docker/Dockerfile args: - 'ARG1=A' - 'ARG2=B'

  5. Commit and push the changes.

You can use images not only from Docker Hub but from any public registry that doesn't require authentication. In case of an image from Docker Hub, you can specify only the image name. For other registries, you must specify the full image URL.

schemaVersion: 2.2.0 attributes: space: instanceType: regular editor: type: Idea components: - name: openjdk-container container: # image from Docker Hub image: openjdk:latest

Warm up the dev environment

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 disk snapshot (or warm-up snapshot) 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 Space runs the warm-up

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. (Optional) 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

How to 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'

Manage warm-up snapshots

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.

Note that storing warm-up snapshots is included in disk storage billing. Learn more about billing.

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

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.

Set environment variables

To define environment variables in a dev environment container, use the components.container.env parameter.

schemaVersion: 2.2.0 attributes: space: instanceType: large editor: type: Idea components: - name: dev-container container: env: - name: VAR_A value: 'valueA' - name: VAR_B value: 'valueB'

When creating a new environment, you can view the added variables under Environment variables.

Env vars in dev environments

After you push the updated devfile to the project repository, the specified environment variables will be available only in the newly created dev environments.

Provide project parameters and secrets to a dev environment

You can provide a dev environment with parameters and secrets that are common for the entire project, for example, URLs, file paths, common auth tokens, and so on.

To reference the required project parameters and secrets, use the project's devfile. A dev environment will take the values from the project's storage of secrets and parameters.

  1. Open the project.

  2. On the project sidebar menu, choose Settings, then Secrets and Parameters.

  3. Click Create and choose Secret or Parameter.

  4. Specify

    • Key: a parameter name. You will use this name to reference this parameter in the devfile.

    • Value: a parameter value.

    Limitations:

    • Secrets and parameters exist only in the scope of a particular project. So, if you create a secret or a parameter in one project, you cannot use them in other projects.

    • Keys of secrets and parameters must be unique within a project. A secret and a parameter with the same key are also not allowed.

    • A key must be no longer than 128 characters and can only contain alphanumeric characters ([a-z], [A-Z], [0-9]), dashes (-), or underscores (_).

    • Keys are case-insensitive.

    • Max secret's or parameter's value size is 30KB.

  5. To reference the created project secrets and parameters in a devfile, assign them to environment variables. The parameter or secret name (key) must be preceded with the project: prefix. For example:

    # suppose we created a project parameter 'service-url' # and a project secret 'auth-token' schemaVersion: 2.2.0 attributes: space: instanceType: large editor: type: Idea components: - name: dev-container container: env: - name: URL value: '{{ project:service-url }}' - name: TOKEN value: '{{ project:auth-token }}'

Provide personal parameters and secrets to a dev environment

You can require users to provide personal values for particular dev environment parameters and secrets. For example, these could be user credentials for downloading project binary dependencies. The required parameters and secrets are available on a target dev environment as environment variables.

To define the required environment variables (i.e., parameters and secrets), use the project's devfile. When creating a dev environment, a user will be asked to provide variable values. The values must be taken from the personal user storage of secrets and parameters.

To define the required environment variables

  1. Open the devfile in the project repository. If it doesn't exist, create a new one, for example, .space/devfile.yaml.

  2. Specify the required environment variables. For example, we require an environment variable DB_USERNAME (the value is expected to be a plain parameter) and a variable DB_TOKEN (the value is expected to be a secret):

    schemaVersion: 2.2.0 attributes: space: instanceType: large editor: type: Idea requiredParameters: - name: DB_USERNAME description: 'Database username' requiredSecrets: - name: DB_TOKEN description: 'Database access token'
  3. Commit and push the changes.

    After this, when creating a dev environment, a project developer will be required to provide values for the defined secrets and parameters (this has to be done only for the first created environment; all subsequent environments will have these settings pre-defined).

To assign personal secrets and parameters to the required environment variables

  1. On the Personal navigation sidebar, click Dev Environments, then click Environment Variables.

  2. Create a parameter or a secret by clicking New parameter or New secret.

  3. Specify

    • Key: a parameter/secret name.

    • Value: a parameter/secret value.

  4. When creating a new dev environment, in the New Dev Environment window, under Environment variables, assign environment variables to the corresponding parameters and secrets.

    Env vars in dev environments. Secrets

    Note that the specified environment variables are set only in newly created dev environments. There will be no such variables in the existing dev environments.

Configure JVM options for IntelliJ-based IDEs

In some cases, you might need to change the configuration of Java Virtual Machine (JVM) your IntelliJ-based IDE runs on. For example, increase the maximum memory heap size allocated for the IDE.

To specify the required JVM options, use the vmoptions list. For example, to set the initial and max memory heap size allocated for the IDE:

schemaVersion: 2.2.0 attributes: space: editor: type: WebStorm # the config appends to the default .vmoptions file vmoptions: - '-Xms2048m' - '-Xmx4096m'

After you push the updated devfile to the project repository, the specified JVM options will be applied only to newly created dev environments.

Specify the project root directory

After you start a dev environment, an IDE opens a project root directory. By default, the project root is the repository root. You can specify an alternative project root location (relative to the repository root) using the projectRoot parameter. This might be helpful for mono-repositories which include multiple projects.

Also note that all path parameters in a devfile (e.g., components[*].image.dockerfile.uri and components[*].image.dockerfile.buildContext) are specified relative to the project root.

# resulting project root: <path-to-repo>/server schemaVersion: 2.2.0 attributes: space: editor: type: Idea projectRoot: server
# projectRoot is not specified # resulting project root: <path-to-repo> schemaVersion: 2.2.0 attributes: space: editor: type: Idea
Last modified: 01 March 2023