-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
Recursive DeepMerge function #25032
Recursive DeepMerge function #25032
Conversation
Codecov Report
|
Thank you very much ! |
This is a useful gem indeed because it allows you to create compact and portable code when it comes to complex objects. Without it, merging complex objects requires writing nested |
Awesome, thank you for your work on this. I played around with it (on commit values.tf
Then, running Working as intended
Panic: "value is not a collection"
Panic: inconsistent map element types
I'll see if I have any luck modifying the implementation to address these. |
@jbergknoff-rival thanks for the feedback. I'll take a look at that scenario as well. I wouldn't be surprised if I missed a couple edges cases here, I tried to go for as generic an approach as possible |
@bruceharrison1984 I took a stab at this (diff and new code). There were two problems that I saw:
I refactored a bit so However, I broke support for dynamic and/or unknown values. I don't understand exactly what these are or how they're handled, so I didn't work more on this. It might be easy to re-add support, for all I know. Also: there's some ambiguity about how I hope that's useful. Feel free to use any of this or scrap it. |
@jbergknoff-rival You beat me to the punch 😆 I had refactored both of the issues you had pointed out, but I think I like your implementation a bit better with the return type detection pulled out into another func. I'll go ahead an incorporate your changes in to what's here. Looks like only one test is failing, and it's due to UnknownVal's. I also agree with your take on using Nulls to remove values, and empty brackets to keep them. Seems like a simple enough solution. Your changes have been cherry-picked in, and the failing tests are commented out for now |
Added back support for dynamic/unknown types. All tests are passing again. |
Nice! Thanks again. We're going to start incorporating this in our custom build of TF. With any luck, the PR will get some attention from the maintainers 🤞 . |
Did you consider to do this as external provider with data source which outputs result of deepmerging? This way you will be independent from hashicorp PR approval/merging process. Correct me please if i'm wrong. |
This is totally awesome! We would also need this urgently! Hope the maintainers merge it soon. Thanks for all your effort! |
Dear @aicarmic! Can we add this pull request into the Terraform code. All seems there, even the doc is present and it seems to be functional. It would save lots of people lot of additional effort. Just like when having for example an overall general config map which one wants to combine/merge with a more specific config map in single workspace config files. |
Can't wait to see this in the next release... Will it be added to 0.13 only? |
@jbergknoff-rival would you mind completing the CLA on the off chance this gets merged at some point? |
Hm, I've actually already signed it. I just had a conversation like this a couple of days ago on hashicorp/go-getter#218 (comment) :). I think it's a glitch in the CLA status thing. |
Any update on this? |
@jbergknoff-rival might you need to do the same fix that you applied here? hashicorp/go-getter#218 (comment) |
Thanks for the reminder, @ScottFinlaysonGMSL . I don't have push access to the PR branch, but I think @bruceharrison1984 can do it to fix the CLA. Bruce, if you would amend the commits on your branch, made by me, to use the email address found here, then I think the CLA check will pass. Since it's a rewrite of history, it will require force pushing the PR branch. |
@jbergknoff Looks like it's all fixed up now. Thanks for the heads up |
Apologies if this is a controversial question but if deepmerge only adds functionality that the current merge function lack (but acts mostly the same), why not just augment this functionality into the merge function? Having a similar but slightly different function seems fiddly at best and confusing at worst. FWIW, I love that this capability is being added. |
@bgmonroe A new function was created because there could very well be cases where someone took advantage of the fact that the current merge function only operates at the root level. If this outright replaced it, it could cause failures due to the behavior change. If accepted, this could eventually replace the original merge, but I think a phased roll out would give people time to refactor their templates to conform to the new behavior. Thus a new function was born. |
looking at this. |
Pushing for this PR! @bruceharrison1984 |
While waiting for that PR to be merged, I built a module to do this in pure Terraform. It seems to be working, but I could use some more testers! https://registry.terraform.io/modules/Invicton-Labs/deepmerge/null/latest |
There is ongoing discussion with HashiCorp around this in the original Issue. I'd suggest posting your thoughts there if you wish to be involved with the discussion. |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Description
This function duplicates the existing behavior of the
merge
function, and supplements it with recursive scanning to child objects. This fixes scenarios where you may want to do a partial update of a nested object, but the currentmerge
function can't perform it due to it only operating at the root level. Any type can be overridden with a different type by a later map/object.A new function was created to avoid breaking code that relies on the current
merge
behavior.Tests
All the original
merge
unit tests were copied, and pass againstdeepmerge
. Additional tests were added for overriding child properties.Example