Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0.13: [Bug]: changes to terraform initRoot stack do not invalidate provider status cache #6039

Open
twelvemo opened this issue May 14, 2024 · 0 comments

Comments

@twelvemo
Copy link
Collaborator

twelvemo commented May 14, 2024

Garden Bonsai (0.13) Bug

Current Behavior

A change in a terraform stack which is applied by garden as part of the provider initialization via initRoot does not invalidate the provider status cache. This means that unless using --force-refresh the terraform stack is never updated.

Expected behavior

The stack deployed as initRoot should when changed cause a cache miss.

Reproducible example

garden.yaml:

apiVersion: garden.io/v1
kind: Project
name: terraform-s3

environments:
  - name: dev

providers:
  - name: terraform
    initRoot: terraform
    autoApply: true
    environments: [dev]

terraform/main.tf

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.65"
    }
  }
  required_version = ">= 1"
}

provider "google" {
  project = "***"
  region  = "eu-central1"
}

resource "google_storage_bucket" "static-site" {
  name  = "garden-tf-root-stack-${md5(timestamp())}"
  location      = "EU"
  force_destroy = true
}

The above terraform config changes the bucket name on each apply.

Workaround

Using --force-refresh causes a provider re-initialization and therefore the change is detected.

Suggested solution(s)

The stack deployed as initRoot should when changed cause a cache miss.

Additional context

Your environment

  • OS: macOS

garden version 0.13.30

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants