-
Notifications
You must be signed in to change notification settings - Fork 115
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
Do a deep merge on bindings rather than a shallow #419
Conversation
d4c4510
to
0a2f705
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please rebase so we can get the tests ✅ before merge.
0a2f705
to
774aecd
Compare
Rebase done |
@@ -7,7 +7,15 @@ module KubernetesDeploy | |||
module BindingsParser | |||
extend self | |||
|
|||
def parse(string) | |||
def parse(binds) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this PR is 👍 functionality-wise, but I feel like this class's API is a bit weird now--it's not intuitive what the difference is between BindingsParser::parse
and BindingsParser::parse_binding
would be.
Here's a suggestion:
# If you need multiple, you do:
bindings = KubernetesDeploy::BindingsParser.new
# ...
opts.on("--bindings=BINDINGS", "...") { |b| bindings.add(b) }
# ...
bindings.parse
# But you can still also use the exact same API as before:
KubernetesDeploy::BindingsParser.parse(bindings_string)
module KubernetesDeploy
class BindingsParser
def self.parse(string)
new(string).parse
end
def initialize(initial_string=nil)
@raw_bindings = Array(initial_string)
end
def add(string)
@raw_bindings << string
end
def parse
result = {}
@raw_bindings.each do |string|
# parse/merge
end
# etc
result
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, refactored
983ee09
to
f6daf34
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ready to ship after typo fix and tophat
exe/kubernetes-deploy
Outdated
@@ -38,6 +37,7 @@ ARGV.options do |opts| | |||
exit | |||
end | |||
opts.parse! | |||
bindings = bindings.parse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be parser.parse
, which reminds me that someone needs to tophat all affected executables before we merge this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I did my tophat with render
🤦♂️
f6daf34
to
8503d24
Compare
I was able to confirm successful 🎩 using the |
What are you trying to accomplish with this PR?
Make it possible to have multiple overlapping configurations that will be deep merged to form one sane configuration.
Eg. lets say you have following configurations:
common.yaml:
and then you have environment specific one:
production.yaml:
Currently we only merge top level entries with
merge
so eg. iflb_id
was on top this would be fine but for more complex configurations people tend to separate things in to nested entries. Another example could be eg. settingresources
but overriding limits in certain env, think of:and then in
nonprod
you wanna override therequests
for example.How is this accomplished?
deep_merge!
instead ofmerge!
tl;dr
s/merge/deep_merge
but I thought its cleaner to pull the loop in to the parser too. Makes testing lot more easier and harder to screw up if doing changes in both deployer and rendererWhat could go wrong?
Things dont get parsed, world blows up.
Seriously though, if someone is relying on the wrong behaviour (shallow merge) this might cause a surprise, but technically doing so is wrong .. so :)