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