Explicit relation between ImagePolicy and ImageUpdateAutomation

[tun0]

Scenario:

Application consisting of a combination in-house developed software (think: PHP application) and third-party software (think: Elasticsearch, Redis, etc).
For the in-house developed stuff, we want IUA to actively deploy the latest versions based on ImagePolicies.
For third-party stuff, we want IUA to create branches/PRs based on ImagePolicies.

Current workarounds:

• Hard separation between in-house and third-party stuff directory-wise, and have specific ImageUpdateAutomation resources pointing at those respective directories.
• Separate them by using different namespaces for both instead.

Suggested solution:

Think: Ingress classes
In each ImagePolicy you explicitly (with perhaps some optional default) configure which ImageUpdateAutomation is supposed to "process" this ImagePolicy.

[makkes]

In general I agree that it's sometimes hard to reason about the relationship between ImageUpdateAutomation and ImagePolicy resources and how they interact with each other. I myself ran into this with two ImageUpdateAutomations living in a namespace and racing against each other, leading to one of them always failing to push changes.

Here's a link to a discussion with some background on the decisions behind the current design and Michael asked exactly the question you're posing here: "is it useful to have two automations refer to the same (part) repo?".