Dev Environment Lifecycle

Lifecycle scripts

You can run custom shell scripts at different stages of a dev environment's lifecycle. This can be helpful in various automation scenarios like work time tracking, personalized environment setup, project configuration, or any other custom actions.

To configure lifecycle scripts, use the Lifecycle scripts settings. You can add your custom scripts to the following stages:

• On initialization

  Run your script when a dev environment is initialized. This event is triggered only once when the environment is created for the first time. This stage is the earliest in the lifecycle – it happens before any actions in the environment (personal user parameters aren't available at this stage). You can use this event to perform tasks that require the IDE or project sources, e.g., configuring the IDE. Though, we recommend that you prefer the warm-up script for such tasks.

  Warm-up: The initialization script runs in warm-up environments as well. If the script was run during the warm-up, it won't be executed in the user's environment.

• On activation

  Run your script every time a dev environment is activated. This event is triggered every time a user activates the environment, for example, by creating it, taking it from the standby pool, or re-activating it after it is stopped. Personal user parameters are available at this stage. Use this event to run update automation or for tasks that require user context. For example, this is a perfect stage to log in to a Docker registry on behalf of the user or to run docker-compose up that starts external services like databases, cache servers, etc.

  Warm-up: The activation script doesn't run in warm-up environments.

For each stage, you can add a script that will be run in the environment's container and a timeout for the script execution. Note that running scripts affects the environment's start and stop times, so use this feature with caution.

Auto-stop

The Auto-stop settings let you save resources by automatically stopping dev environments:

• Inactivity timeout (minutes)– the period of inactivity after which the dev environment will be automatically stopped.

  What does inactivity mean?

  A dev environment is considered inactive if:

  • The user doesn't perform any actions in the IDE client (mouse clicks, keyboard input) or in SSH sessions (commands execution).

  • The user closes the client; that is, they close the IDE window (while keeping the dev environment running) or put the computer to sleep/turn it off.

  Inactivity time doesn't include any other background activities. For example, if the user runs a build and minimizes the IDE window, the dev environment will be stopped after the inactivity timeout regardless of the build process.

  Known issue: If a process writes to the console, the dev environment is considered active. Temporary workaround: Closing the IDE client starts the inactivity timer anyway.

Important: The dev environment will be stopped anyway after 48 hours of continuous work. A system administrator can change this default limit during the installation using the application.config.codecanvas.execution.k8s.worker.activeDeadline parameter of the Helm chart.