Open richardcase opened 3 years ago
@richardcase - I would like to take this up. When is this 0.4 milestone planned? How frequently we make releases?
The 0.4 release is planned for Friday this week. I've moved this to 0.5 which will happend in Jan. There is no specific release cadence, just when there are enough new featues or fixes.
@ramnar - are you still interested in doing this change?
@richardcase Ya Iam still interested to do it.I got busy with something. I will submit draft patch by next sunday
@richardcase Ya Iam still interested to do it.I got busy with something. I will submit draft patch by next sunday
No rush @ramnar and thank you for contributing 👍 If you have any questions feel free to reach out to me....happy to help in anyway I can.
@richardcase - I went through existing source code and understood to some extent on how existing commands are implemented.
I implemented dummy runconfig command. Created runconfig_types function containing the structure to hold content of the yaml file. I tried to create deepycopy functions using code generator but nothing got updated in the zz_generated function. Can you guide me on how to do this code generation thing correctly?
The way Iam trying to implement is to read the input yaml file and put into a structure variable. Then implement the logic to run all the commands for all clusters iteratively.
Also I want to understand on the different packages being used for creating the command. I was trying to understanding the config command. I see the code scattered into various packages. I would like to understand what should go into pkg/config and internal/app packages.
@richardcase - Also I think we should integrate spell checker during the linting process. I saw couple of spelling mistakes while reading the comments.
@ramnar - sorry for the delay in replying. If you had some changes on a fork i'd be happy to talk about specifics.
The zz_generated.deepcopy.go
is created by running make generate
. This uses code generators that run against structs defined in this folder: ./api/v1alpha1
. When the code generators run they understand special comments in the files like this.
The Configuration is a good one to copy as a starting place. There is a separate package that then reads a file into this struct, see this.
Code in internal/app
represents the top level "application". It has the main entry point functions to actual logic of what kconnect does (i.e. not the plumbing around the cli itself). As its in a internal
folder we are specifically designating that its not to be imported into other projects. Anything in the /pkg
could be resused by other projects if they so wanted.
@richardcase - Looks like there is no unit testing framework in place. Can you confirm on the same? How can i generate the documentation for the new command?
@ramnar - we are using Ginkgo, Gomega, GoMock for the places we do unit testing. We need to add more tests especially from a e2e perspective around the app
. Example of existing tests: https://github.com/fidelity/kconnect/blob/main/pkg/history/store_test.go
The documentation can be regenerated using make docs-generate
Create a new command to batch run kubectl commands across a number of clusters using the aliases setup.
From the discussion we'd use a file to configure the commands to run and aliases
And then run it
kconnect run -f run.yaml --password mypassword123
Originally posted by @seankelly001 in https://github.com/fidelity/kconnect/discussions/227#discussioncomment-195396