-
Notifications
You must be signed in to change notification settings - Fork 87
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
Enable receiving a rest config on TestSuite #360
Conversation
Signed-off-by: Ali Felan <alifelan@google.com>
@alifelan I'm curious why you provided the deepcopy func... if removed... the
which keeps all the copy code in the same place. I've not taken over the deepcopy functionality before... and thus don't know the pros/cons (yet). However it would be great to keep in the generated place which would allow for refactoring that is tied to the same mechanism (generation). Thoughts? |
I'm otherwise good! Allowing for a response / update if appropriate. Looking to merge after we agree on approach. thanks for the contribution! |
Sure, the problem with the generated code is that
DeepCopy will create only the methods that are missing, enabling us to define our custom ones. That is useful for the I think the same on keeping the code in the same place, but we cannot keep it in the generated file since it would be overwritten whenever we generate new code. I was thinking about creating Let me know your thoughts on 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.
/lgtm
thanks for the explanation... all makes sense to me. Thanks for sticking with it! |
Signed-off-by: Ali Felan <alifelan@google.com> Signed-off-by: Israel Blancas <iblancasa@gmail.com>
Signed-off-by: Ali Felan alifelan@google.com
What this PR does / why we need it:
PR #348 was missing the generated deep copy code. When added, that code had a problem since
rest.Config
does not implementDeepCopy
, but has the method available from the promotedrest.TLSClientConfig
, which when being used onrest.Config
ended up breaking the code.There were several solutions considered, each having its downsides:
Harness
. Downsides were exposing a field for one specific use case, and also having to rename theConfig
methodHarness
, which would be copied toHarness.config
. Same as before, having a field for one specific use case wasn't the bestDeepCopy
method with the custom copy forrest.Config
. In this scenario, theDeepCopy
method would no longer be autogenerated.The implemented solution was having a struct that embeds the
rest.Config
. While doing that, we can implement our customDeepCopyInto
method, usingrest.CopyConfig
. After this, the generated code will be compatible. To avoid repeated names while getting the config fromTestSuite
, the field was namedRC
.To avoid running into the same problems as the previous PR, I ran
generate
,cli
, andall
targets from the Makefile.Fixes #347