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

kubernetes

-type Deploy action that deploys a Kubernetes Deployment which specifies a pod with a container using the image produced by a Garden

container

-type Build action:

yaml
kind: Build
type: container
name: api
---
kind: Deploy
type: kubernetes
name: api
dependencies: [build.api]
spec:
  files: [my-manifests.yml]
  manifests:
    - apiVersion: apps/v1
      kind: Deployment
      spec:
        template:
          spec:
            containers:
              - name: api
                image: ${actions.build.api.outputs.deployment-image-id} # <--- The output from the Build action above

In this example, the

container

-type Build action is used to build the source code. The

kubernetes

-type Deploy action then deploys the built image to a Kubernetes Deployment. The image used for the container in the Deployment is specified using Garden template strings (

${actions.build.api.outputs.deployment-image-id}

), which Garden will resolve to the correct image before applying the manifest. You can find more details about this in the Garden documentation (). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

message has been deleted

---------------------- The value of

deployment-image-id

is determined by the Build action in Garden. Specifically, it is the full ID of the image (including tag/version) that the Build action will use during deployment. Here's an example of how it's used:

yaml
my-variable: ${actions.build.my-build.outputs.deploymentImageId}

In this example,

my-variable

would be assigned the full ID of the image that the

my-build

Build action uses during deployment. This value is a string and is used for backward compatibility as an alias for

deploymentImageId

. You can find more details about this in the Garden documentation (). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

message has been deleted

---------------------- In Garden, the image tag is automatically generated and it's based on the content of your source code and your configuration files. This means that each build may have a different tag, and the

latest

tag is not used by default. However, if you want to manually tag an image as

latest

, you can use the

garden publish

command with the

--tag

option. Here's an example:

bash
garden publish my-container --tag="latest"

This command will publish the

my-container

image and tag it as

latest

. Note that this command is used to publish the image to a remote Docker registry. If you're using the

local-kubernetes

provider and want to tag the image as

latest

locally, you can use a

Run

action with a

docker image tag

command, like this:

yaml
kind: Run
name: local-container-tag
type: exec
dependencies:
- build.my-container
spec:
command:
- docker
- image
- tag
- ${actions.build.my-container.outputs.localImageId}
- ${actions.build.my-container.outputs.localImageName}:latest

This will tag the latest build of

my-container

as

latest

locally. Please note that using the

latest

tag can lead to confusion and is generally not recommended for production use, because it's not clear which version of the image

latest

actually refers to. It's usually better to use explicit version tags. You can find more details about this in the Garden documentation () and in the Discord support thread (). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

message has been deleted