Skip to main content
Planned. This page describes designed behaviour that is not built yet. Details may change before it ships.
Ported from Garden’s documentation: garden-for/containers/building-containers.md, gliss-cli at 3bc62a036 (Garden 0.14). Gliss runs Garden under the hood; the notes on this page say where Gliss differs.
You build container images with the container Build action:
If there is a Dockerfile in the same directory as this file, that is enough to tell Garden to build it. To use another file, set spec.dockerfile: <path-to-Dockerfile>. You can also explicitly include or exclude files in the build context.
In Gliss, builds run in your company’s own CI, with the container or exec Build types. There is no remote or hosted container builder and no in-cluster building. CI pushes the images to your company’s container registry (Amazon ECR in your AWS account), and a release request names each image by its digest. See CI with GitHub Actions.

​
Use the image in other actions

Most commonly you’ll then want to deploy the image, or use it in Test or Run actions. You do that by declaring the Build as a dependency and referencing its outputs with template strings such as ${actions.build.api.outputs.deployment-image-id}.
In Gliss, a container Deploy maps to a gliss-service, so it is checked against the same catalog as gliss.yaml. Deploying the image with your own Helm chart or Kubernetes manifests is level 2 only.
For example, at level 2 you can pass the image to a Helm chart:

​
Set build arguments

You can specify build arguments using the spec.buildArgs field. This is handy when you reference another Build action as a build dependency:
Garden also sets GARDEN_ACTION_VERSION as a build argument automatically. It holds the version of the action being built, which you can use to set versions, render docs or clear caches.

​
Use an existing image

If you don’t build the image yourself and just need to deploy one that already exists in a registry, set image in the Deploy action’s spec:

​
Build for several platforms

Use the platforms field to build for several platforms and architectures:
Your CI runner’s Docker setup must support multi-platform builds, for example with a docker-container buildx builder. See Docker’s multi-platform build documentation.
In Gliss, Garden’s garden publish flow and publishId are not how images reach your clusters. Publishing an app to Live promotes the exact images that ran in Beta; see Share and publish.