Let customers ignore specific properties in stack what-if (similar to Terraform's ignore_changes)

Abierto
#268 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Área
cloud

Línea de trabajo

Start by reading the stack what-if implementation and the related drift detection issue #117 and tag noise issue #253; this request does not name source files or tests. The work needs a design for how ignored properties are declared on resources or stacks and how ignored differences appear in results. Done means customers can configure ignored property paths and see those differences identified as ignored.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Is your feature request related to a problem? Please describe.

Raised by a customer that reviews stack what-if results in pull requests. Some properties on their stack-managed resources are expected to change outside the template. For example, an Azure Policy (DeployIfNotExists) sets a tag with when and how a resource was last changed, including manual changes, so the template never sets it. Stack what-if reports those differences, so today they strip them out of the what-if JSON with a script before deciding whether anything changed.

Whether a difference like this is noise depends on the customer's setup, so it's hard for the platform to decide it for them.

Describe the solution you'd like

A way for customers to mark properties as ignored in stack what-if, similar to ignore_changes in Terraform:

  • on a resource in the template, for example with a decorator, and
  • for a whole stack, for example a list of property paths or tag names.

Ideally, ignored differences would still be listed as ignored rather than dropped, so it stays clear what was filtered out.

Describe alternatives you've considered

  • Setting every default explicitly in the template. That works for provider defaults, but not for values another process owns, like a policy-set tag.
  • Carrying the current value forward with this.existingResource(). What-if doesn't evaluate it yet (Azure/arm-template-whatif#83), so the property still shows as a change.
  • Filtering the what-if output with a script, which is what they do today.

Additional context

Related: Azure/bicep#3931 (ignore tag changes, closed after no recent activity), Azure/bicep#8729 (preserving existing properties during a deployment), #117 (drift detection) and #253 (tag noise in stack what-if). An ignored property is also drift the customer has chosen not to track, so this overlaps with drift detection.

Lenguaje dominante
Bicep
Estrellas
103
Forks
13
Métricas de merge de PR
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Azure/deployment-stacks

Todos los issues de Azure/deployment-stacks

Issues similares

Más issues de Cloud

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.