From ac6563453722c69c474a2a45de694d8c18e0e776 Mon Sep 17 00:00:00 2001 From: Thorarinn Sigurdsson Date: Mon, 10 Feb 2025 10:38:29 +0100 Subject: [PATCH] chore: more doc tweaks --- docs/terraform-plugin/about.md | 6 ++---- docs/terraform-plugin/actions.md | 4 ++-- docs/terraform-plugin/configure-provider.md | 2 +- 3 files changed, 5 insertions(+), 7 deletions(-) diff --git a/docs/terraform-plugin/about.md b/docs/terraform-plugin/about.md index 2a6171e6de..2331744a35 100644 --- a/docs/terraform-plugin/about.md +++ b/docs/terraform-plugin/about.md @@ -50,12 +50,10 @@ garden --env= plugins terraform apply-root -- -auto-approve For example, running `garden deploy --env dev` and `garden deploy --env ci` will pick the appropriate backend for the environment. -If you'd like to apply the stack when starting Garden (e.g. because you're provisioning a Kubernetes cluster and need to pass the outputs to other Garden providers), checkout [the Terraform provider docs for configuring dynamic backends](./configure-provider.md#setting-the-backend-dynamically). +If you'd like to apply the stack when starting Garden (e.g. because you're provisioning a Kubernetes cluster and need to pass the outputs to other Garden providers), check out [the Terraform provider docs for configuring dynamic backends](./configure-provider.md#setting-the-backend-dynamically). If instead you configure your Terraform stack via actions (e.g. because you have -multiple AWS labmdas that should each have their own stack), checkout [the Terraform -action docs for configuring dynamic -backends](./actions.md#setting-the-backend-dynamically). +multiple AWS labmdas that should each have their own stack), check out [the Terraform action docs for configuring dynamic backends](./actions.md#setting-the-backend-dynamically). ## Next steps diff --git a/docs/terraform-plugin/actions.md b/docs/terraform-plugin/actions.md index 59b460c4e6..2fe9c471ed 100644 --- a/docs/terraform-plugin/actions.md +++ b/docs/terraform-plugin/actions.md @@ -52,10 +52,10 @@ defaultEnvironment: dev environments: - name: dev variables: - tfNamespace: ${kebabCase(local.username)} # <--- Each user has their lambda + tfNamespace: ${kebabCase(local.username)} # <--- Each user has their own set of lambdas - name: ci variables: - tfNamespace: ${slice(git.commitHash, 0, 7) || ''} # <--- Each CI run has their lambda + tfNamespace: ${slice(git.commitHash, 0, 7) || ''} # <--- Each CI run has its own set of lambdas --- kind: Deploy diff --git a/docs/terraform-plugin/configure-provider.md b/docs/terraform-plugin/configure-provider.md index 1a6b875e64..2ee5135139 100644 --- a/docs/terraform-plugin/configure-provider.md +++ b/docs/terraform-plugin/configure-provider.md @@ -54,7 +54,7 @@ In the example below we can imagine a Terraform stack that provisions a Kubernet We achieve this via the `backendConfig` field on the `terraform` provider spec which can make use of Garden's powerful templating system. -This means you can run `garden deploy` (for the dev env) and it'll use the corresponding backend. From the same host you could then run `garden deploy --env` without needing to update your config and manually re-intialize Terraform and it'll again pick the correct backend. +This means you can run `garden deploy` (for the dev env) and it will use the corresponding backend. From the same host you could then run `garden deploy --env` without needing to update your config and manually re-intialize Terraform, and it will again pick the correct backend. ```yaml # In project.garden.yml file