build
build copied to clipboard
knative
Allow events to initiate Builds
The eventing controller seems to be focused on routing events to Elafros apps via routes.
If it were also possible to initiate builds in response to events of all of the types supported by eventing, we could make a big stride toward a general-purpose K8s-native CI platform, supporting builds in response to webhooks, or on a schedule, or in response to PubSub events, etc. If builds were able to automatically trigger deployments, we'd get CD as well.
Sharing these concepts and triggering infrastructure could help reduce new code that would have to be written and maintained, and new concepts that would have to be understood by users.
From my understanding of the eventing API model, it seems like we could start by adding a TemplateInstantiationSpec field to BindAction, which would instantiate the specified BuildTemplate with provided arguments to generate a build to execute.
Beyond that, we'd probably want some way to dynamically pipe values from the event itself to the triggered template instantiation, to be able to pass values like the Git commit SHA that triggered the build, or the time the scheduled build was invoked, or values from the PubSub message, etc.
I'm open to ideas about how best to do that, or if I'm thinking about this in the wrong way and there's a better way to piece things together.
Another option would be to have a small function to create the Build from an Event, particularly if there are logic-specific details like extracting branch/SHA hashes and selecting a template.
On Tue, Apr 3, 2018 at 7:32 AM Jason Hall [email protected] wrote:
From my understanding of the eventing API model, it seems like we could start by adding a TemplateInstantiationSpec https://github.com/elafros/build/blob/8fbf994e0055a31aeaa71b512fefadb7c7432b56/pkg/apis/build/v1alpha1/build_types.go#L53 field to BindAction https://github.com/elafros/eventing/blob/58174ee129205d2aec3f62b98fc7cf5694535855/pkg/apis/bind/v1alpha1/bind_types.go#L38, which would instantiate the specified BuildTemplate with provided arguments to generate a build to execute.
Beyond that, we'd probably want some way to dynamically pipe values from the event itself to the triggered template instantiation, to be able to pass values like the Git commit SHA that triggered the build, or the time the scheduled build was invoked, or values from the PubSub message, etc.
I'm open to ideas about how best to do that, or if I'm thinking about this in the wrong way and there's a better way to piece things together.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/elafros/eventing/issues/34#issuecomment-378271288, or mute the thread https://github.com/notifications/unsubscribe-auth/AHlyNykp5hvdjj2bAovQeg836cmetfiEks5tk4gOgaJpZM4TFKKZ .
-- Evan Anderson [email protected]
That might be possible, but I'm worried that ties Build CRD too closely with Elafros itself.
In the long-term, I'd love for it to be possible to install the Build CRD controller, and future related CI/CD controllers (possibly including Eventing), possibly without Elafros' controllers, if the user doesn't want to have a full serverless platform installed, and just wants on-cluster CI/CD.
Having Eventing be able to trigger Builds directly is part of that long-term vision.
It should be possible to use the Eventing CRD with a regular webserver, so you could just have a regular (rather than serverless) deployment which creates the builds.
On Tue, Apr 3, 2018 at 10:18 AM Jason Hall [email protected] wrote:
That might be possible, but I'm worried that ties Build CRD too closely with Elafros itself.
In the long-term, I'd love for it to be possible to install the Build CRD controller, and future related CI/CD controllers (possibly including Eventing), possibly without Elafros' controllers, if the user doesn't want to have a full serverless platform installed, and just wants on-cluster CI/CD.
Having Eventing be able to trigger Builds directly is part of that long-term vision.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/elafros/eventing/issues/34#issuecomment-378328269, or mute the thread https://github.com/notifications/unsubscribe-auth/AHlyNxhzq0jCb3WIgqITa_G_VAkQRLjjks5tk67pgaJpZM4TFKKZ .
-- Evan Anderson [email protected]
This is a great use case and should definitely be in our samples folder. I think it's both useful and a good litmus test for how we can eventually support it without hard-coding that support.
The first step should be to make Bind.Spec.Action more generic. This will let us deploy a Bind (reminder: that CRD name will change) that sends events which should trigger a build to the builder service. What sort of trigger are you most interested? Git commits to master? pull requests? If there's a good use case from another event source that would be great too.
In the long-term, I'd love for it to be possible to install the Build CRD controller, and future related CI/CD controllers (possibly including Eventing), possibly without Elafros' controllers, if the user doesn't want to have a full serverless platform installed, and just wants on-cluster CI/CD.
Having Eventing be able to trigger Builds directly is part of that long-term vision.
^ Exactly what I am looking for :)
Being able to install only the Pipeline and Eventing CRDs to trigger a PipelineRun based on a GitHub events, for example, would be really great! (as explained here)
@ImJasonH @evankanderson any update on this? Thanks
The current githubsource in https://github.com/knative/eventing-sources using Knative Serving as part of its implementation.
If you can find a github event deliver-er which doesn't use serving, then you should be all set. (You could probably change the implementation to use a Deployment, but you'll have one or more Pods running for each GitHub webhook, whereas with Serving mostly you'll have zero Pods except when GitHub webhooks are happening.)
We have a GitHub event source which can be wired directly or indirectly to anything which matches the Addressable duck type.
Since an HTTP POST of a CloudEvent is unlikely to directly create any Kubernetes resources, Build probably needs to figure out how to use a CloudEvent to create a Kubernetes object. Moving to Build.