Fix: implement prevent_auto_deploy flag to allow configuration updates without triggering deployments

[jackcloudquery]

Issue & Steps to Reproduce / Feature Request

prevent_auto_deploy is respected when an env0_environment is created, but is
ignored on update. Changing configuration, revision, variable_sets, template_id,
or sub_environment_configuration on an existing environment triggers a deployment (run) -
even though the environment is explicitly flagged not to auto-deploy. Teams that manage the
shape of their environments with Terraform but run deployments themselves (CI/CD, behind
review gates) get runs kicked off outside their pipeline including production.

Minimal repro

resource "env0_environment" "this" {
  name                = "example"
  project_id          = env0_project.this.id
  template_id         = var.template_id
  prevent_auto_deploy = true

  configuration {
    name  = "FOO"
    value = "bar" # change to "baz", apply -> a deployment is triggered
  }
}

After changing value to "baz", terraform apply queues a new deployment on the
environment (env0 → Activity) instead of just updating the variable.

Root cause: shouldDeploy decides whether to deploy on update purely from which fields
changed and never consults prevent_auto_deploy, so the update path always hits the deploy
endpoint.

Solution

On update, when prevent_auto_deploy is set, the provider no longer queues a deployment.
Instead it persists what env0 can apply without a run, directly:

• configuration and sub_environment_configuration.*.configuration - written via the
  configuration endpoints (create / update / delete per variable).
• variable_sets - assigned / unassigned via the configuration-set assignment endpoints.
• revision / template_id - these only take effect as part of a deployment, so under
  prevent_auto_deploy they're kept declaratively in state and applied by the user's own
  deploy. The read no longer overwrites them from the latest deployment log, avoiding
  perpetual drift.

This mirrors what the env0 backend already does at create time (createWithoutDeploy):
on create the provider just sends preventAutoDeploy in the payload and the backend forks;
on update there's no equivalent endpoint, so the provider makes the same decision client-side.

Notes (by design):

• A revision change under prevent_auto_deploy is recorded in state but is a no-op until the
  next deployment; external changes to revision/template_id are not surfaced as drift
  (documented on the field).
• Variables are persisted with sequential per-variable calls (not atomically like the deploy
  endpoint); a mid-loop failure leaves a partial apply that Terraform reconciles next run -
  same behavior as the standalone env0_configuration_variable resource.

After the fix the repro updates FOO to baz with no deployment queued, and
terraform plan afterwards reports No changes.

---

Manual E2E verification:

• Built the provider locally, wired in via dev_overrides, ran against the env0 dev stack
• Created an env0_environment with prevent_auto_deploy = true and a configuration
  variable (self-contained config: project + template + assignment + environment)
• Changed the variable value and revision, then terraform apply → no new
  deployment on the environment (env0 → Activity) and the variable value is updated
  (env0 → Variables)
• terraform plan after the apply → No changes. Your infrastructure matches the configuration. (no drift on the variable or revision)
• Unit tests cover update / create / delete of variables under prevent_auto_deploy
  (asserting ConfigurationVariableUpdate/Create/Delete fire and EnvironmentDeploy does
  not), variable-set assign/unassign, sub-environment configuration, and
  revision/template_id drift suppression

Re @liranfarage89 (WORKFLOW-scoped top-level config): confirmed. The env0 backend treats
WORKFLOW as a first-class scope on the direct /configuration write
(assert-configuration-scopes.ts) and returns it for the matching workflowEnvironmentId
query (find-by-scope.ts) - the exact query the provider's read issues. Verified end-to-end via
an API round-trip on the dev stack: a direct scope=WORKFLOW write returned HTTP 200 and was
persisted (scopeSortKey=WORKFLOW:<envId>), then read back with scope=WORKFLOW, scopeId=<envId>.

Closes https://linear.app/env-zero/issue/APO-96/preventautodeploy-is-ignored-on-certain-environment-updates

[Copilot]

Pull request overview

Implements support for prevent_auto_deploy during environment updates, allowing certain changes to be persisted in env0 without triggering a deployment/run (addressing APO-96).

Changes:

• Updates environment update flow to persist changes without calling deploy() when prevent_auto_deploy = true.
• Adds helper functions to compute/apply configuration + variable set changes directly via API calls.
• Expands unit test coverage and updates resource documentation for prevent_auto_deploy.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
env0/resource_environment.go	Adds updateWithoutDeploy flow, helper functions for configuration scopes/changes, and updates prevent_auto_deploy behavior on read/update.
env0/resource_environment_test.go	Adds unit tests ensuring configuration, variable sets, and sub-environment configuration can persist without triggering deployments when prevent_auto_deploy is enabled.
docs/resources/environment.md	Updates the resource docs description for the prevent_auto_deploy flag.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[yarivg]

@jackcloudquery how did you QA it? mind sharing the example to the PR desc

[jackcloudquery]

@jackcloudquery how did you QA it? mind sharing the example to the PR desc

Added to the PR description

[liranfarage89]

LGTM. All comments addressed — verified the WORKFLOW-scope create against the backend + live round-trip, the per-sub-env guard, and the new create/delete test. CI green. 🙏