I think it would be beneficial to consider a segmented package structure for the existing controllers package, in a way that would make the code more organized and abstracted by generally defined verticals. This could also help us define meaningful interfaces for subpackages and allow for greater maintainability of the code base going forwards
An initial idea for what the new package structure could look like:
As a part of this I would propose to include the following changes:
each sub package contains its own utils.go for package specific utility functions. Utility/utils.go could be reserved only for truly generic utility functions that can be used project-wide
existing watchers.go and reconcile.go contents be consolidated in argorollouts_controller.go since their contents are closely related (and performed by) the main argorollouts_controller.go
getPolicyRules should be moved out of utils.go and into the RBAC subpackage since it is central to the rbac functionality more than just being a utility function
I think it would be beneficial to consider a segmented package structure for the existing controllers package, in a way that would make the code more organized and abstracted by generally defined verticals. This could also help us define meaningful interfaces for subpackages and allow for greater maintainability of the code base going forwards
An initial idea for what the new package structure could look like:
As a part of this I would propose to include the following changes:
utils.go
for package specific utility functions.Utility/utils.go
could be reserved only for truly generic utility functions that can be used project-widewatchers.go
andreconcile.go
contents be consolidated inargorollouts_controller.go
since their contents are closely related (and performed by) the main argorollouts_controller.gogetPolicyRules
should be moved out ofutils.go
and into theRBAC
subpackage since it is central to the rbac functionality more than just being a utility function