4th step for Investigate and propose package repositories API with similar core interface to packages API. #3496 #4573
Conversation
| }; | ||
| } | ||
|
|
||
| // this endpoint only exists for the purpose of integration tests |
There was a problem hiding this comment.
Not sure about having an actual extra endpoint for the integration tests?
There was a problem hiding this comment.
Well, I had a problem. I have a bunch of integration tests for AddRepository and GetRepositoryDetail. Once I split the server-side functionality of user-managed secrets and kubeapps-managed secrets a number of tests became invalid. For example, I had a test that would GetRepositoryDetail and return detail with secret refs. That only works with user-managed secrets. kubeapps-managed secrets would return Username/Password, etc. So I wanted the flexibility of switching from user-managed to kubeapps-managed and back while the server is running so that I can have a new test that returns Username/Password and the existing test that returns secretRefs. All while the server is running. My only way to do that is via a gRPC call. That's why the endpoint. The endpoint is only in the flux-specific API, BTW, not in the core API. In the future we may change how the flag works, so I may get rid of the endpoint
There was a problem hiding this comment.
Yeah, fine for now. If we need this kind of thing longer term, we could probably have a test plugin for example.
sorry about that Michael, I didn't think it would be that difficult to review. Really the there are 2 things in there: 1) separate the functionality of user-managed vs kubeapps-managed secrets based on a flag like we discussed and 2) just added empty stub for UpdateRepository (no implementation for plug in, just the core). Once again, I will try to do better next time |
Oh - I didn't isolate it into those two when going through - seemed to be other refactoring too, which I wasn't sure whether it was changing code (tracking where it's deleted and added etc.)
Heh - it's not that big a problem, no need for penance :P, I'm just keen to be able to review things properly and find it difficult when it's not clear to me what has changed. I should have re-read the PR description after reading through, as you'd identified what had changed pretty clearly there. |
4th step for Investigate and propose package repositories API with similar core interface to packages API. #3496
Changed AddPackageRepository and GetPackageRepositoryDetail to reflect latest design spec with user-managed vs kubeapps-managed secrets. For now, store the flag in plugin config, because it is easier to change on demand for unit tests than say, a kubeapps global setting. This is temporary, just until we settle on if/where to hang it.
Most of the changes are either in generated files or in unit test code