Dev Environment Lifecycle
CodeCanvas lets you configure the lifecycle of dev environments in the Lifecycle section of a dev environment template.
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. For each script, you can set a timeout to prevent long-running scripts. Note that running scripts affects the environment's start and stop times, so use this feature with caution.
To configure lifecycle scripts, use the Lifecycle scripts settings. You can add your custom scripts to the following stages:
Run your script when a dev environment is initialized. This stage is the earliest in the lifecycle – it happens before any actions in the environment.
When is it triggered? This event is triggered only once when the environment is created for the first time.
Are personal user parameters available? No, you can't refer to personal user parameters in the initialization script.
Is it triggered during warm-up? Yes, the initialization script runs in warm-up dev environments as well. If a dev environment is created from a warm-up snapshot where the initialization script was already run, the script won't be executed in this environment.
Use cases: You can use this script to perform tasks that require the IDE or project sources, such as configuring the IDE. However, we recommend that you prefer the warm-up script for such tasks.
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 was stopped. Personal user parameters are available at this stage.
When is it triggered? This event is triggered every time a user activates the dev environment, for example, by creating it, taking it from the standby pool, or re-activating it after it was stopped.
Are personal user parameters available? Yes, you can refer to personal user parameters in the activation script.
Is it triggered during warm-up? No, the activation script doesn't run in warm-up environments.
Use cases: Use this script 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.
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.
Max session duration (minutes)– the maximum time a dev environment can be active without stopping. After this period, the environment will be automatically stopped regardless of the activity. By default, the session duration is 600 minutes (10 hours).
A system administrator can change the default auto-stop values during the installation using the Helm chart parameters:
application:
config:
codecanvas:
execution:
timeouts:
autoStop:
defaultNoBackgroundActivityDuration: 30m # default for 'Inactivity timeout (minutes)'
defaultTotalSessionDuration: 10h # default for 'Max session duration (minutes)'
Thanks for your feedback!