-
Notifications
You must be signed in to change notification settings - Fork 3
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
Add CI tests #10
Add CI tests #10
Conversation
@rainest assuming (also based on the commits) this PR is basically this other PR plus tests, can we use |
Sure. |
"github.com/fatih/color" | ||
"github.com/google/go-cmp/cmp" | ||
"github.com/google/go-cmp/cmp/cmpopts" | ||
"github.com/kong/deck/cmd" |
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.
Hm as noted in the linked issue this might not be breaking the build but is rather undesirable 🤔
Couldn't we leave whatever's using the cmd
in deck repo and test here without resorting to deck commands? This way we'd break up the dependency. Not sure how feasible that is given that most of the code here relies on issuing requests against Kong (or Konnect) via the cmd
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.
As designed the integration tests are very much designed around using the CLI commands as they would be used at the CLI. We could build a pseudo-CLI to call the various package functions in sequence here, but in practice that code would be almost identical to the CLI minus cobra and such. IDK how much we'd need the separation in form if not function to meet the goals of the separation--that's more a question for @Tieske probably.
My hope is that after the initial separation we do continue with further refactors to make the packages and their APIs here better designed as modular components, and in the course of those refactors we write new integration tests that slowly replace the original deck ones.
Is there, alternately, a way to automatically run an external repo's tests against a PR branch as part of that PR's checks? We have good reason to run deck and KIC tests against proposed library changes regardless. Being able to do that without actually importing their packages here feels less backwards, for lack of a better word.
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.
If you wanted to run deck and/or KIC tests with changes in this repo then simply checking those out via something like https://github.com/Kong/kubernetes-ingress-controller/blob/44ef693b3cae49a55475cde4097af28739f36918/.github/workflows/release_docs.yaml#L26-L31 and then:
go mod edit -replace=github.com/kong/go-database-reconciler=../go-database-reconciler
go mod tidy
(assuming checkout to the same parent dir)
As for the refactors: 👍. It would be highly desirable to remove that (semi-)circular dependency between this repo and deck.
We'd basically need to peel off one layer (cmd invocation) and use the actual library code (but that's just my speculation). deck tests should be left as is anyway to utilize this lib in its integration suite.
|
1 similar comment
|
da02ed2
to
45deed3
Compare
Re-added Codecov now that I've realized this doesn't require an org admin to configure and added a token. In deck (and KIC) we weirdly have the CODECOV_TOKEN in a |
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 cleanup comments
Co-authored-by: Gabriele Gerbino <[email protected]>
This reverts commit 7cd0ca6.
Will it test? That is the question.
Essentially copying the test CI and code from deck after Kong/deck#1109. Will need to figure out what to snip out later.