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

Allow defining global dynamic fields rules #30

Closed
czeslavo opened this issue Dec 18, 2023 · 5 comments · Fixed by #40
Closed

Allow defining global dynamic fields rules #30

czeslavo opened this issue Dec 18, 2023 · 5 comments · Fixed by #40

Comments

@czeslavo
Copy link

Context

I have a use case in which I would like to test multiple test values files located in a single directory (let's say, named tests). For every values file, my Helm chart generates Kubernetes Secrets with dynamically generated data. Secrets are always named the same. Now, to make my tests pass, I need to separately add the same testSpec.dynamicFields to every test values file which is redundant. I would like to be able to define global dynamicFields-like rules that would be used when generating snapshots for every values file in my tests directory.

Expected behavior

It's possible to set a global dynamic fields configuration that is used for every values file. Dynamic fields configuration is used to replace all dynamically generated content with ###DYNAMIC_FIELD### constant when the rule matches an object's field.

Sample command:

 helm chartsnap -c <chart> -f <directory-with-test-values-files> --dynamic-fields-config=./exclude-secrets-data.yaml 

Sample config file (exclude-secrets-data.yaml):

  dynamicFields:
    - apiVersion: v1
      kind: Secret
      name: chartsnap-postgresql
      jsonPath:
        - /data/postgres-password

Alternatively, this could be a config file used by the tool, e.g. .chartsnap.yaml in which the global configuration would be defined (I believe there could be more global settings to tune than just dynamicFields in the future).

@jlandowner
Copy link
Owner

Hi @czeslavo
Thank you for raising!

I totally agree with you. I'll work on this soon.

Alternatively, this could be a config file used by the tool, e.g. .chartsnap.yaml in which the global configuration would be defined (I believe there could be more global settings to tune than just dynamicFields in the future).

dynamicFields can be various by charts so it cannot be global for the user environment(e.g. home dir).

I think it is good to place .chartsnap.yaml in your test values directory to configure common behavior of your chart snapshots.

What do you think about it?

@jlandowner
Copy link
Owner

jlandowner commented Dec 19, 2023

Also in the case of dynamicFields are found in .chartsnap.yaml and individual test values files, we need to merge them or override with one of them.

I think merging is better for dynamicFields. it is not so difficult to merge as duplication does not make problems, probably.

@czeslavo
Copy link
Author

I think it is good to place .chartsnap.yaml in your test values directory to configure common behavior of your chart snapshots.

Yeah, that sounds like a good idea. It could be the default behavior while you still could use a CLI argument to override it.

Also in the case of dynamicFields are found in .chartsnap.yaml and individual test values files, we need to merge them or override with one of them.

I think that merging two slices should be fine even without deduplicating entries. I understand that if there are two rules for the same Kind and its field, the result will be the same as if there was only one.

@jlandowner
Copy link
Owner

@czeslavo Thank you for your response. I'll work on it soon👍

@jlandowner
Copy link
Owner

@czeslavo I've published a new release. Please check it out!

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