microscopic-river-74022
01/22/2024, 1:31 AMmicroscopic-river-74022
01/22/2024, 1:31 AMenvironment[].variables key in your project configuration. This allows you to provide different values for different environments. Here's an example:
yaml
kind: Project
variables:
log-level: info
environments:
- name: local
variables:
log-level: debug
- name: remote
In this example, the log-level variable will have the value debug in the local environment and info in the remote environment. You can then reference these variables in your actions using the ${var.<key>} syntax.
For more complex conditional logic, you might need to handle that in your application code or in the scripts that you run as part of your build or deploy actions.
For more information, you can refer to the Garden documentation on variables and templating ().
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------flat-state-47578
01/22/2024, 1:51 AMmicroscopic-river-74022
01/22/2024, 1:51 AMmicroscopic-river-74022
01/22/2024, 1:51 AMyaml
kind: Deploy
type: container
spec:
replicas: "${environment.name == 'prod' ? 3 : 1}"
In this example, the replicas attribute of the deploy action will be set to 3 if the environment.name is prod, and 1 otherwise.
You can use a similar approach to conditionally set the build attribute of a deploy action based on an environment variable. For example:
yaml
kind: Deploy
type: container
spec:
build: "${environment.name == 'prod' ? 'build-prod' : 'build-dev'}"
In this example, the build attribute will be set to 'build-prod' if the environment.name is prod, and 'build-dev' otherwise.
For more information, you can refer to the Garden documentation on variables and templating ().
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------flat-state-47578
01/22/2024, 1:53 AMbuild is left undefined depending on the environment variable? E.g.:
build: "${local.env.GARDEN_DEV_SERVICE == "my-service" ? 'my-service' : null }"microscopic-river-74022
01/22/2024, 1:53 AMmicroscopic-river-74022
01/22/2024, 1:53 AMnull might not be the best approach as it could lead to unexpected behavior or errors.
If you want to conditionally disable the build process for a specific service, you could use the disabled field instead. Here's an example:
yaml
kind: Build
name: my-service
type: container
disabled: "${local.env.GARDEN_DEV_SERVICE != 'my-service'}"
In this example, the build process for my-service will be disabled if GARDEN_DEV_SERVICE is not equal to 'my-service'.
For more information, you can refer to the Garden documentation on variables and templating ().
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------