-
Notifications
You must be signed in to change notification settings - Fork 203
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
Implement the Convertible interface on non-hub resources #1628
Conversation
cf37d2b
to
813f382
Compare
b2b1ec5
to
60d27fd
Compare
92f2e98
to
7a5ba94
Compare
df32912
to
e9e04cf
Compare
7a5ba94
to
8890b7e
Compare
8890b7e
to
994c3b5
Compare
3520a61
to
9a876ce
Compare
994c3b5
to
55dd583
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.
Some minor comments but looks good overall
injector := astmodel.NewInterfaceInjector() | ||
|
||
modifiedTypes := make(astmodel.Types) | ||
resources := storage.FindResourceTypes(state.Types()) |
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 feel like this method (and the others in types_tools
that are generic) should be moved to astmodel along with your interface/function injectors?
Reading this made me think it was finding the storage resource types or something, I had to go look at the impl to understand it was just any old resource type.
Your FindStatusTypes
could probably replace my findAllResourceStatusTypes
in remover.go
as well, although we could leave that for another PR because it'll require changing some types around I think.
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.
Agreed. I'm sure moved these into astmodel
in a later PR, not sure which one off the top of my head.
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.
Would you consider pulling it forward? I've got at least one upcoming PR where I'd like to use the Status one.
hack/generator/pkg/codegen/pipeline/implement_convertible_interface.go
Outdated
Show resolved
Hide resolved
"github.com/Azure/azure-service-operator/hack/generator/pkg/test" | ||
) | ||
|
||
func TestInjectConvertibleInterface(t *testing.T) { |
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.
Should this test be replaced with a standard json
input file + golden file once the stages are actually enabled in the pipeline?
If so, consider leaving a TODO here to that effect?
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.
No, the purpose of this test is to test this pipeline stage in isolation (well, as much isolation as possible). I don't want to conflate the results of this test with other things happening to independent stages.
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.
Added a comment.
@@ -57,6 +57,11 @@ func (iface *InterfaceImplementation) References() TypeNameSet { | |||
return results | |||
} | |||
|
|||
// FunctionCount returns the number of included functions | |||
func (iface *InterfaceImplementation) FunctionCount() int { |
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.
Would it make more sense to just expose this as Functions()
like exists on ResourceType
? (Can we do that since this is also embedded there?)
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.
Functions returns a copy (by necessity), whereas this can return the count directly. Not that we're too performance sensitive, but that's why I added. it. 😁
// | ||
// Direct conversion from the hub type: | ||
// | ||
// func (r <receiver>) ConvertFrom(hub conversion.Hub) error { |
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.
minor: use the From|To
notation you used below to clarify that this can also happen in either direction?
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.
Or maybe because you aren't using it super consistently below either (and doing so might make the examples awkward for example in the error messages, etc) instead you could just preface this with something like: "Examples show the From
direction. The only difference between the two is that all instances of From
are replaced with To
in the To
direction." or something?
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've been wavering on whether including <From|To>
actually adds clarity or just makes things harder to read. Adding them in for now.
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 FWIW I agree. In theory I like <From|To>
but in practice it makes things a bit harder to read. I think my main thing here is just be consistent, if you don't use them that's fine you can just have a preface or something that explains roughly how the other direction might look. The comments are meant to help us understand the code rather than be an exact, faithful replica of the template that is being applied so I think either is ok.
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.
At the moment I'm leaning (just) towards keeping them in - it's still easier to parse the comment with <To|From>
than the actual code, and it cues readers into the complexity that's present.
64e9d88
to
131ec1b
Compare
131ec1b
to
3fb22f1
Compare
Codecov Report
@@ Coverage Diff @@
## master #1628 +/- ##
==========================================
+ Coverage 67.22% 67.61% +0.39%
==========================================
Files 208 211 +3
Lines 14979 15175 +196
==========================================
+ Hits 10069 10260 +191
Misses 4151 4151
- Partials 759 764 +5
Continue to review full report at Codecov.
|
What this PR does / why we need it:
Implements the required
ConvertTo()
andConvertFrom()
methods needed by theconversions.Convertible
interface used by the controllerNote that the stage is disabled for two reasons. First is that we don't want to activate this functionality until post
codegen-alpha-0
. Second is that we need to turn on a bunch of features together, otherwise the internal validation of the controller will reject our webhooks.Prerequisites
master
How does this PR make you feel:
If applicable: