Image Change Triggers for build v2 about build

[sbose78]

Yeah, in the build API context, we care about listening to changes on the base image.

Rollouts, inherently should be outside the scope of Shipwright.

Though, if Shipwright has a representation of an Image as a Kubernetes resource, we may possibly define what "listening" to changes in a image might look like, where rollouts is one of the many things.

[adambkaplan]

This isn't a minimum viable feature for GA.

[qu1queee]

@gabemontero if I understand this issue correctly, this seems to be a missing glue code between openshift controllers and build, not sure that this is an item where we need to do something in this repo. If this is the case, can you please close this issue?. If not, lets discuss this card in detail.

[gabemontero]

Yeah this gets to the last part of the description. I think we've subsequently reached consensus since I wrote that descritption that in fact achieving this in shipwright only code would be more expensive than introducing changes in openshift.

We've got tracking in our internal jira feature for this as well (epic BUILD-183). If/when that gets prioritized, we'll assess the landscape and only open an EP etc. if we think changes on the shipwright side would facilitate.

[sbose78]

@gabemontero @imjasonh Does this look like an appropriate one to track Oleg's work?

[imjasonh]

I think we should be careful to describe two separate concepts:

1. "When an image changes in a registry, trigger a deployment of that image" (not necessarily a K8s Deployment, but in general a rollout of the new image). This might look like a new CRD to watch an image in a registry.
2. "When an image changes in a registry, trigger a BuildRun" -- this can be useful for watching base images or images used during multi-stage builds (e.g., golang, etc.). This might look like a field on the Build CRD to watch an image in a registry.

In both cases, "watch" should mean "set up a webhook if you can, but fallback to polling if you can't" (same with SCM-based build triggering too -- #51).

The implementations of these things might look very similar, and their APIs should look similar to users, but I think it'll be useful to separate them conceptually for users, since it's often different people who care about "builds" and "rollouts".

I know OpenShift Builds v1 has features like these (both flavors, I think?), but we don't need to be constrained to that API necessarily if we can think of something that fits better for new users and use cases.

[gabemontero]

I think we should be careful to describe two separate concepts:

1. "When an image changes in a registry, trigger a deployment of that image" (not necessarily a K8s Deployment, but in general a rollout of the new image). This might look like a new CRD to watch an image in a registry.

2. "When an image changes in a registry, trigger a BuildRun" -- this can be useful for watching base images or images used during multi-stage builds (e.g., `golang`, etc.). This might look like a field on the Build CRD to watch an image in a registry.

+1 on these distinctions

In both cases, "watch" should mean "set up a webhook if you can, but fallback to polling if you can't" (same with SCM-based build triggering too -- #51).

The implementations of these things might look very similar, and their APIs should look similar to users, but I think it'll be useful to separate them conceptually for users, since it's often different people who care about "builds" and "rollouts".

I know OpenShift Builds v1 has features like these (both flavors, I think?), but we don't need to be constrained to that API necessarily if we can think of something that fits better for new users and use cases.

it does have both features, but absolutely yes, no API constraints from OpenShift's API should apply here; the motivation solely is a viable migration path IMO .... functional "approximation"

i.e. As a dev, if the base or builder image of my build changes, I want a new buildrun triggered

[gabemontero]

per ^^ we now have shipwright-io/community#25 for starting the conversation of supplying something that approximates openshift imagestreams from within the shipwright ORG of code.

One follow up question @adambkaplan @imjasonh @sbose78 - this issue originally also proposed integrating buildv2 / now shipwright with openshift's image change trigger support (there is some vanilla k8s types that are supported).

Do we want even want to track such support in an upstream github issue? Feels more downstream

I'm thinking no. And as a result, am beginning to lean toward close this in favor for @imjasonh SHIP and any new issues that are opened from its progress.

But I'm not convinced enough to hit the close button without soliciting feedback from you all ... thanks.

[adambkaplan]

I don't see an easy path for integration with OpenShift Imagestream triggers. These seem to work best with resources that are "pod-specable", like Deployments and CronJobs. The trigger works by mutating the image field of a container, which then triggers some kind of rollout [1]. Shipwright builds would need an equivalent "config change" trigger, and even then would only work if a Build object referenced an image in its inputs.

[1] https://docs.openshift.com/container-platform/4.8/openshift_images/triggering-updates-on-imagestream-changes.html#images-triggering-updates-imagestream-changes-kubernetes-about_triggering-updates-on-imagestream-changes

[gabemontero]

All ^^ key and relevant technical details @adambkaplan

To add to them, it really speaks IMO to the fact that any integration at all, and it is not a given, would most likely be at the Tekton level, which has been a subject that has been thrown around in tekton/openshift pipeline

So we either leave this item open as a trigger to us to periodically check in on those efforts ^^ as well as the progression of the potential shipwright version of imagestreams

where our prior conversations here over the last year and a half provides some useful context

Or we close this and open something new if in fact something evolves

I'm leaning toward the latter, but will give @adambkaplan @imjasonh @sbose78 a few more cycles to chime in before doing so.

[sbose78]

Sounds good @adambkaplan @gabemontero . We re-open this one or open a new one, whenever relevant.