squaremo
commented
1 year ago It only needs to handle local application objects if that's easier, but bear in mind the machinery will later need to be generalised to remote clusters (e.g., the index could include the cluster name). Using the standard controller-runtime setup for watching types and indexing dependents won't teach us anything.
On "Using the standard controller-runtime setup for watching types and indexing dependents won't teach us anything" -- that's true; but on reflection, learning is not the main reason for doing this initial bit. Having the "easy" implementation will mean we can get on with the other parts of the larger change (#193). We can do the learning concurrently with other stuff.
It's also easier to watch just HelmRelease (controller-runtime make this especially convenient), so I'm going to allow that too, for the sake of expedience.
Objective
This is to quickly get a basis for implementing the promotion algorithm.
It only needs to handle local application objects if that's easier, but bear in mind the machinery will later need to be generalised to remote clusters (e.g., the index could include the cluster name). Using the standard controller-runtime setup for watching types and indexing dependents won't teach us anything.
User Story As a Pipelines user, I would like to be able to use the feature to see each target's status in the Pipeline status, so that I can understand what's happening.
Location of the Change/Work pipeline-controller
Related Initiative Problem 1
Technical Task breakdown
Acceptance Criteria The work needs to be able to:
~- [ ] Includes tests for invariants~ (EDIT: as noted in the comment below, I narrowed the scope a bit and this is no longer a big deal)
On the final AC: objects that aren't mentioned in a pipeline don't get watched. We don't need to do anything with the watched applications / fetched pipelines other than what's needed to test that it works.