Closed kannon92 closed 1 year ago
+1 on this
@danielvegamyhre which preference would you have for this?
I can see benefits of logic to detect changes being useful but I also wonder if making the client generation explicit and just detecting that api is different would be less brittle and having a check to see if api mismatches and just telling the user they need to run generate step..
Yeah I think option 2 would be the most straight forward. We could make the change detection part of the verify step in the CI.
/good-first-issue /help
@kannon92: This request has been marked as suitable for new contributors.
Please ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue
command.
I'd like to give to this one a shot :) /assign
/close
@a-hilaly: You can't close an active issue/PR unless you authored it or you are a collaborator.
Running unit tests/integration tests will now require regeneration of client-go/sdk every time. I think we should try to make this a bit smarter as it does make unit or integration tests take a lot longer.
I see two options for development:
1) Only build client-go/sdk if the api was changed. 2) Move building of client-go/sdk into a separate target and call it separately from
make
ormake test
ormake test-integration
.Currently it is built alongside
make
so it will run on every build.