-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Stop running make after every command call #1982
Comments
While the time impact of a single call may be considered small, this will have a bigger impact in generating the testdata (both for the developer and the CI) and the potential re-scaffolding from a config file feature that we have talked about where multiple calls to the commands are done once after another and for each one we are generating, formating, vet-ing and building (and even at the end we do another |
Hi @Adirio,
Then, what is the problem that you are trying to solve here? Are you looking for win a few seconds of performance for operations that are executed once or twice in the life? In this way, IMO I do no think that we should move forward with because I cannot see the problem that will be solved with this change. I think it only might introduce an issue in a scenario where would be valid/required runs the make targets and it was not as complexities to define the list of the specific targets that should be executed for each subcommand. |
I've hit cases where this isn't true (especially in resource-constrained situations like CI), and have had situations where I wanted to switch some stuff before make was run, which would've otherwised cause make to fail or do something undesirable (try and pull in new deps, etc)
Perhaps I'm misreading, but my impression was that @Adirio was actually arguing that currently the only users who benefit from FWIW, I'm on board at least for v3. I think it's prob fine for v2 as well -- I've never been super into running the make command after every invocation. |
Answer to @camilamacedo86
Even if it was 100ms, why should we waste that time to do nothing? There is no advantage on running them.
Make flag defaults to true in both plugins. We are manually turning it to false for
You didn't understood this part right. The IDE argument is the only advantage for using the make. And that only requires
Thats not the point, the point is that those operation are completely useless and that's what Im trying to prove.
I already listed all the scenarios that can happen when you run any of those commands. You will always have to do additional changes like writting code yourself and call Answer to @DirectXMan12 Exactly, the IDE is the only minimal advantage of keeping the tests, and it only applies to |
Thank you for the clarifications. I misunderstood your point of the IDE for the first moment. |
Background
Post-scaffold
make
Currently, every
init
,create api
orcreate webhook
callmake
as the last step. There are some cases where this behavior can be disabled with a flag (v2/create-api
,v3/create-api
&v3/create-webhook
) and others can't even be disabled (v2/init
,v3/init
andv3/create-webhook
).make
functionalityA call to make does four things:
DeepCopy
,DeepCopyTo
, andDeepCopyObject
methods for your types.go fmt
go vet
Subcommands functionality evaluation
I will evaluate the need for those four steps for each of the commands.
init
1, 2 and 3 are no-ops, and the manager built by 4 is completely useless. There is no reason to
make
afterinit
.create api
1 and 4 will have to be done after editing and 2 and 3 are no-ops. The only reason I see to do this is to have the
DeepCopy
,DeepCopyTo
andDeepCopyObject
methods recognized by IDEs while you are writting the code, which would only requiremake generate
and only in the case a new API was scaffolded.create webhook
1 has no use, 2 and 3 are no-ops, and 4 will have to be done after editing. There is no reason to
make
afterinit
.go fmt
andgo vet
will just hide those style errors.Conclusions
So the basic conclusion is that running
make
after any of these command calls is useless. You are either doing work that was already done or that you will need to do after editing the scaffolded files. Onlymake generate
aftercreate api --resource
has a very small positive effect of having IDEs recognize this methods. However, the user will still need tomake generate
after adding any field.Proposal
make
call from all post-scaffold methodmake generate
call to thecreate api
post scaffold method in case a new type file is generated.--make
flag inv3/create-webhooks
I think we should do this to go/v2 and go/v3. It won't have a real impact on the user so I think they should be considered backwards compatible and thus applied to both plugins Removing the
--make
flag only needs to be applied to go/v3 and we haven't released any stable version of the go/v3 plugin so I think we should be able to do it./kind feature
The text was updated successfully, but these errors were encountered: