Feature request .envignore

[jrauschenbusch]

For more advanced compare operations like in GitOps repositories and automated environment promotion it‘s often required to exclude known but accepted differences.

It would be really good to have a mechanism like a .gitignore file, but for diffs. Furthermore it would be good to be able to exclude files and just subset of env vars of a file.

Maybe in TOML

[[excludes]]
path = "/path/to/.env"
keys = [ "EXCLUDED_1", "^EXCLUDED_.*$" ]

[[excludes]]
path = "/path/toc/other/**/.env"

YAML:

excludes:
  - path: /path/to/.env
    keys:
    - EXCLUDED_1
    - ^EXCLUDED_.*$
  - path: /path/to/other/**/.env

[mgrachev]

@jrauschenbusch Hi! Thank you for your feedback!

We need to think about the implementation, it is possible to make a common configuration file for the entire project.

[jrauschenbusch]

This would help me a lot. And also a lot if others i guess. I also filed a ticket at homeport/dyff#361 as YAML is besides .env files the most common file format for Kubernetes-based deployments. Both together allows Release engineers to build proper automation pipelines for environment promotion. It's often the case that there are resources defined which should not get promoted to all existing environments (e.g. API mocks for external systems due to cost reasons or others reasons)

To be more precise: Sometimes it's not easily possible to divide manifest files into promotable and non-promotable parts (even with Kustomize). Hence automation is not possible to 100% all the time. But especially with ENV vars you want to get informed if variables potentially need to be added manually (e.g. new container image version needs more configuration) or removed manually (replacement of env vars or deprecation => cleanup). This cannot be easily determined via automation rules. Hence one needs a CI Pipeline job, which verifies if manual interactions are maybe required. This job could either fail with an exit code = 1 and print details, or just add a comment to an auto-generated Release PR that manual adjustments are required (or at least a manual verification). Having too many accepted diffs all the time in this report, the automation cannot be implemented in a way that it really reduces the amount of manual verification.