-
Notifications
You must be signed in to change notification settings - Fork 706
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
Merge modifications made in previous versions when upgrading #1278
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
371c9bb
Merge modifications when upgrading
79016ec
Rename function
b0c9655
Add comment and test
3ea0cdf
Fix test
aeb7ac9
Remove unnecessary setProps
63995dc
Fix test
57d8a9d
Merge branch 'master' into jsonPatch
26078a6
Add TODO comment
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
It looks like you're calculating the modifications based on the new selected chart and the default values... which explains why in the test you're setting the modifications by first selecting the original chart (
props.selected
) and basing it on that.This is quite confusing - as above, it's not clear why we don't calculate the modifications once when the component is first created, rather than wrapping the calculation of the modifications in multiple conditions here to ensure it only gets calculated once? Yes, it might be a little more work initially to support that, but in the long run it will save orders of magnitude more person-hours as we review and work on this code - IMO.
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.
Sorry for the confusion in the test because it's not properly written but as I said, when the component is first created (in the real scenario) the
selected
property is empty so we cannot get the modifications at that moment. It's not until the code in the line 55 is executed when we have that information available. That's why I wrap this in the condition. This hook will be executed every time the user selects a new version but we are only interested on calculating the modifications the first time since at that moment is when the version matches the already deployed chart.In any case, I plan to change this once we change the UX experience to pre-select the latest version available, I just didn't want to add more changes to this PR (also because I am not sure yet how that will look like).
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.
Thanks for the update.
Right, but that's because of confusion (in the implementation) on the
selected
property I think? That is, we should not be calculating any user modifications on the current deployment based on theselected
field - it's only working here because you're passing through the currently deployed chart as theselected
version initially (hence the confusion in the code).Sorry to be pushing back, but I really think stuff like this is important... I get that it all makes sense to you currently in your head, with the context, but it won't be clear to anyone else (and not you either at a later date). It'd be slightly better if there was a chunk of comment explaining why it's being done the way it is, but afaict, but better to avoid the confusion in the code itself.
My main question is: Why are we mis-using the
selected
prop of theDeploymentFormBody
, which is for which chart version a user selects in the UI - not which version is already deployed, rather than required prop on theUpgradeForm
? (when the user is upgrading, this info should be required to start the upgrade process).I don't see how that's related at all - we don't need to know the version the user is selecting (or the latest version) to be able to calculate the modifications for the currently deployed chart?
Let's chat about this on the standup (or after). I don't want to block you further, but do want to understand why we're mis-using props like this (or what I'm misunderstanding) before approving.
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.
Thanks Andres. FTR, we chatted and found one piece of info which wasn't clear to me is that in the current implementation, the
selected
field is updated to display the value of the currently deployed version when you upgrade (which we'd want to change to instead default to the most likely upgrade candidate - ie. the most recent version).Andres is going to look at doing this (possibly in another PR), so that we don't need to abuse and depend on the
selected
field to record the currently deployed chart, perhaps extracting to theUpgradeForm
.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.
right, it's also true that it may not necessary to control the behavior of the
DeploymentFormBody
depending if it's for the Upgrade or the Deployment case.