---------------------- The "container run" and "kubernetes-pod run" are two different action types in Garden that are used to execute commands in different environments. The "container run" action is a simplified abstraction that allows you to run a command in a container image, such as in a Kubernetes namespace. However, it has limited features compared to more platform-specific types. For instance, you cannot specify replicas for redundancy, and various platform-specific options are not included. Here is an example of how to use it:

yaml
kind: Run
name: seed-db
type: container
dependencies: [build.api]
spec:
 image: ${actions.build.api.outputs.deployment-image-id} # <--- The output from the Build action
 command: [npm, run, seed-db]

Source () On the other hand, the "kubernetes-pod run" action executes a Run in an ad-hoc instance of a Kubernetes Pod and waits for it to complete. The pod spec can be provided directly via the

podSpec

field, or the

resource

field can be used to find the pod spec in the Kubernetes manifests provided via the

files

and/or

manifests

fields. Here is an example of how to use it:

yaml
kind: Test
name: vote-integ-pod
type: kubernetes-pod
dependencies:
 - deploy.api
variables:
 hostname: vote.${var.baseHostname}
timeout: 60
spec:
 resource:
 kind: Deployment
 name: vote-integ-pod
 command: [/bin/sh, -c, "npm run test:integ"]
 values:
...

Source ()

In summary, the "container run" action is a simpler and more limited option for running commands in a container, while the "kubernetes-pod run" action provides more flexibility and is more suitable for complex tasks that require the full features of Kubernetes. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

@microscopic-river-74022 show me an example of kubernetes pod run with the manifests

---------------------- Sure, here's an example of a

kubernetes-pod

run action with the

manifests

field. Please note that the actual Kubernetes resource manifests are not provided in the knowledge sources, so I'll use placeholders for them:

yaml
kind: Run
name: my-run-action
type: kubernetes-pod
spec:
  manifests:
    - apiVersion: <api-version> # replace with your API version
      kind: <kind> # replace with your resource kind
      metadata:
        name: <name> # replace with your resource name
      spec: <spec> # replace with your resource spec
  command: ["/bin/sh", "-c", "your-command"]

In this example,

manifests

is an array of Kubernetes resource manifests. Each manifest is an object that describes a Kubernetes resource. The

apiVersion

,

kind

,

metadata.name

, and

spec

fields are required for each manifest. The

command

field specifies the command to run in the pod. Please replace

<api-version>

,

<kind>

,

<name>

, and

<spec>

with your actual Kubernetes resource details. For more information, please refer to the Garden documentation (). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

@microscopic-river-74022 i want only run a deploy when i set an --var cronjobs=true how should the deployment should look like?

---------------------- To conditionally run a deployment based on a variable, you can use the

enabled

field in your deployment configuration. The

enabled

field accepts a template string, which can include variables. Here's an example:

yaml
kind: Deploy
name: my-deploy
type: container
enabled: ${var.cronjobs == "true"}
spec:
  # your deployment spec here

In this example, the deployment

my-deploy

will only be enabled if the

cronjobs

variable is set to

"true"

. You can set the

cronjobs

variable using the

--var

flag when running the

garden deploy

command:

bash
garden deploy --var cronjobs=true

Please note that the

enabled

field is not specifically documented in the provided knowledge sources. However, it's a common pattern in Garden and other similar tools to use variables for conditional logic. For more information on using variables in Garden, please refer to the Garden documentation (). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

---------------------- I apologize for the confusion. You're correct, the

disabled

field is used in Garden to conditionally disable a deployment. Here's how you can use it:

yaml
kind: Module
type: container
name: my-module
services:
  - name: my-service
    disabled: ${{var.cronjobs != "true"}}
    # rest of your service configuration

In this example, the service

my-service

will only be deployed if the

cronjobs

variable is set to

"true"

. You can set the

cronjobs

variable using the

--var

flag when running the

garden deploy

command:

bash
garden deploy --var cronjobs=true

If

cronjobs

is not set to

"true"

, the service will be disabled and not deployed. For more information on using variables in Garden, please refer to the Garden documentation (). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

---------------------- I apologize for the confusion earlier. You're correct, if a variable is not defined, Garden will throw an error. To avoid this, you can use the

defined

function in your template string to check if the variable is defined. If it's not defined, you can default to

true

(i.e., the deployment is disabled). Here's how you can do it:

yaml
kind: Module
type: container
name: my-module
services:
  - name: my-service
    disabled: ${{defined(var.cronjobs, true) != true}}
    # rest of your service configuration

In this example, the

defined

function checks if

var.cronjobs

is defined. If it's not, it defaults to

true

. The

!= true

part ensures that the service is disabled if

var.cronjobs

is not

"true"

. You can set the

cronjobs

variable using the

--var

flag when running the

garden deploy

command:

bash
garden deploy --var cronjobs=true

If

cronjobs

is not set or not

"true"

, the service will be disabled and not deployed. For more information on using variables in Garden, please refer to the Garden documentation (). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

---------------------- Based on the provided knowledge sources, there is no specific variable in Garden that directly indicates whether the current job is a cleanup job. However, Garden does provide a way to specify a cleanup command for a service. This is done using the

services[].cleanupCommand[]

configuration key. Here's an example:

yaml
kind: Module
type: exec
name: my-module
services:
  - name: my-service
    cleanupCommand: ["your-cleanup-command"]
    # rest of your service configuration

In this example,

your-cleanup-command

is the command that will be run to clean up the service, e.g. when running

garden delete env

. For more information, please refer to the Garden documentation (). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------