Decoupling image-automation-controller from GitRepository (or not)

[squaremo]

This issue asks "Why doesn't the ignore field of GitRepository also apply to image automation?". It's a reasonable expectation, since each ImageUpdateAutomation object points at a GitRepository object in order to get access to a git repo, and it would be handy to be able to tell it to ignore some files and directories in a repo.

However, the reuse of GitRepository in the automation controller is really only a convenience -- it happens to have the couple of fields needed, and there's some code to extract the required authentication from the secret. The fields other than url and secretRef in a GitRepository aren't consulted, because they are designed for use by the source controller.

The ignore field could also be usefully interpreted by the automation controller (and have a similar meaning), but other fields are more of a stretch. What is the controller to make of a commit ref, or the interval field? Should it do something special when the git repository is suspended (ImageUpdateAutomation objects have their own suspended field)?

This leads to a dissonance which is likely to get worse. For example, if fields are added to GitRepository, the expectation is that they have some interpretation for the automation controller.

I can see a handful of ways out of this situation:

Include the url and secretRef (and ignore) fields in the image update automation object

It's not a huge advantage to be able to share a GitRepository definition between syncing and automation. Since automation needs a deploy key or token with write permissions, and syncing doesn't, you might wish to have separate secrets anyway. And the syncing and the automation can be in different clusters entirely.

So the URL and secretRef fields may as well be in the automation object, along with 1. other fields that happen to have a useful meaning in both places, like ignore and 2. any new fields that are relevant to automation specifically.

Have a different object kind for automation targets

I'm reluctant to add types, but there is an argument for having a distinct type to represent the target of automation, especially if we think there will be other controllers or specialised requirements for automation targets. While those are hypothetical, the solution above this is better, however.

Factor the access part of GitRepository out of the source(-controller) part

The bit of the GitRepository that the automation controller needs is the URL and the secret. The source controller needs that, as well as some extra specification of how to use the git repository as a source (e.g., the interval, and the git ref to follow). The usual advice would be to factor the part they have in common out as its own object. However, introducing more types in the API is onerous for the developers and moreover, for users, so should be carefully weighed -- I include this alternative mainly for the sake of completeness.

[squaremo]

Another consideration: it's plausible that automation could be performed against bucket sources as well as git repos. That would add weight to both sides of the scales, since --

• it makes more sense to refer generically to a source whether it's a git repo or a bucket (or some kind that comes along later); but,
• it means the automation is coupled to the fields in both kinds of source spec; and,

Since the fields in ImageUpdateAutomation are all to do with git, they would have to be rearranged, into something like:

spec:
  sourceRef:
    kind: GitRepository|Bucket
    name: whatever
  update:
    strategy: Setters
  git?:
    checkout: { ... }
    commit: { ... }
    push: { ... }
  bucket?:
    # ... maybe nothing ...

[squaremo]

GitRepository field	can it be used for automation?
.url	Yes, already used
.secretRef	Yes, already used
.gitImplementation	Yes, already used
.interval	No, would have to ignore
.suspend	No, would ignore
.ignore	Maybe, could use to filter files updated*
.timeout	Maybe, could use as timeout when cloning
.reference.branch	Maybe, as a fallback for .spec.checkout.branch
.reference.tag	Maybe, if you also required a .push.branch
.reference.semver	As for tag; of dubious utility
.reference.commit	As for tag; of dubious utility
.verification	Maybe, could be useful as a safeguard

• *but unclear whether you would want this to line up with .ignore when used as a source for syncing.

Bucket field	can it be used for automation?
.provider	Yes, would be necessary
.bucketName	Yes, would be necessary
.endpoint	Yes, necessary
.insecure	Yes
.region	Yes
.secretRef	Yes
.interval	No, would ignore
.timeout	Maybe
.ignore	As for GitRepository (including footnote)
.suspend	No, would ignore