Comments (11)
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.
from build.
This isn't a minimum viable feature for GA.
from build.
@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.
from build.
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.
from build.
@gabemontero @imjasonh Does this look like an appropriate one to track Oleg's work?
from build.
I think we should be careful to describe two separate concepts:
- "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.
- "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.
from build.
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
from build.
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.
from build.
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.
from build.
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.
from build.
Sounds good @adambkaplan @gabemontero . We re-open this one or open a new one, whenever relevant.
from build.
Related Issues (20)
- (Cluster)BuildStrategy CR about buildpacks are outdated HOT 1
- Missing custom resource definitions when installing build strategies HOT 3
- README is not match tag HOT 3
- README is not match tag
- Update Heroku sample strategies to heroku-22 stack HOT 1
- `make install` fails at creation of buildruns CRD
- e2e tests failing with `no kind is registered for the type v1alpha1.Build` HOT 5
- Ensure SecurityContext of Controllers are inline with Kubernetes PSA HOT 2
- [BETA API] Provide a solution to automatically create TLS secret and inject caBundle HOT 5
- CVE-2023-37264: Tekton Pipeline Vulnerability Impact on Shipwright
- [BUG] spec.buildSteps[4].securityContext.runAsUser: Invalid value: "string" HOT 4
- [BUG] Docs: Broken link, question about BuildRun
- [FEATURE] Periodic maintenance of existing releases artifacts HOT 3
- [FEATURE] Remove APIVersion from the Strategy struct HOT 1
- [BETA API] With the v1beta1 changes introduced, need to determine the scope for test changes required HOT 3
- Not able to push image into gitlab container registry from last 2-3 days HOT 3
- [FEATURE] Provide a Spec guideline for CRs for moving to v1beta1 HOT 1
- [FEATURE] Implement Build Output Vulnerability Scanning
- [BUG] Runtime error when using a buildRef field in v1beta1 buildrun object spec HOT 1
- [BUG] e2e test cases missing for LocalSource HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from build.