approve_plan_automatically attribute fails for sub_environment

[asafsb]

Describe the bug When adding approve_plan_automatically attribute to a sub_environment, using either true or false values, a failure occurs with the following error:

│ Error: could not create environment: 400 Bad Request: approval flow can't be enabled on workflow environments
│ 
│   with env0_environment.example_with_hcl_configuration,
│   on main.tf line 15, in resource "env0_environment" "example_with_hcl_configuration":
│   15: resource "env0_environment" "example_with_hcl_configuration" {
│ 

To Reproduce

1. Create an env0_environment resource with sub_environment_configuration
2. Add approve_plan_automatically attribute to one of the sub environments
3. Run apply

terraform {
  required_providers {
    env0 = {
      source = "env0/env0"
    }
  }
}

provider "env0" {
  api_key    = var.env0_api_key
  api_secret = var.env0_api_secret
}

resource "env0_environment" "example_with_hcl_configuration" {
  name        = "test workflow approval policy"
  project_id  = var.project_id
  template_id = var.template_id

  is_remote_backend = "true"

  sub_environment_configuration {
    alias    = "vpc"
    revision = "main"
    approve_plan_automatically = "true"
  }

    sub_environment_configuration {
    alias    = "eks"
    revision = "main"
    approve_plan_automatically = "true"
  }
}

Expected behavior Automatic approval plan should be enabled/disabled on the sub environment, as per the documentation: https://registry.terraform.io/providers/env0/env0/latest/docs/resources/environment#nested-schema-for-sub_environment_configuration

Provider Version latest (1.20.6) and 1.19.3

Screenshots

[TomerHeber]

Blocking this ticket since it's a backend issue.

[weinguy-env0]

Hey @TomerHeber and @asafsb, after checking out the backend - the error it does make sense and it should be an improvement from the provider side, let me explain - The error indicated that the environment itself requires approval - which shouldn't be the case for a workflow environment. This is because we want the deployment to start and only check for approval for sub-environments.

This issue has a patch and a long-term fix -

@asafsb for now you just need to add approve_plan_automatically true to the env0_environment resource @TomerHeber for a better user experience we could set approve_plan_automatically to false for workflow environments. I don't know the provider logic too deeply but you should have two options - if you already check for the template type as part of the deploy request you can check for workflow type and set approve_plan_automatically according to the type, and if that information isn't part of the flow you can set it if an env0_environment resource contains sub_environment_configuration resource.

[TomerHeber]

hi @weinguy-env0

Unfortunatly, the backend treats UserRequiresApproval as a tri-boolean (this isn't the only field that has this problem):

1. undefined.
2. true.
3. false.

Ideally, the backend shouldn't have tri-booleans, as this causes alot of confusion (E.g. this issue). But I guess it is what it is.

If I understand you correctly, you would want UserRequiresApproval to be explicitly false or true instead of undefined for workflow templates?

[weinguy-env0]

yeah tri-boolean can be really confusing, I see how this can be missed easily. For workflow templates, we would want UserRequiresApproval to always be false for the environment. If it isn't we will throw an error. If we can we should make it transparent for the user.