Triggers beyond SHIP-0031

[adambkaplan]

In #68, the proposal is for Shipwright to have native triggering support for BuildRuns. Out of the gate the proposal supports the following:

• GitHub
• Tekton Pipelines (between and within pipelines)
• Image changes

It is clear from the discussion that we will need to go beyond these and have more general-purpose mechanisms for adding triggers. See the suggestions for ArgoCD Workflows (#68 (comment)) and CD Events (#72).

Let's discuss:

1. What things would you like to trigger a Shipwright BuildRun?
2. What things would you like to trigger after a Shipwright BuildRun completes?

[adambkaplan]

cc @otaviof @SaschaSchwarze0 @lizzzcai @afrittoli @gabemontero

[otaviof]

In #68, the proposal is for Shipwright to have native triggering support for BuildRuns. Out of the gate the proposal supports the following:

• GitHub
• Tekton Pipelines (between and within pipelines)
• Image changes

For the record, the initial GitHub support described on #68 is based on Push and PullRequest WebHook events.

While GitHub Actions and other relevant events that GitHub shares via the same channel are under research, and should be discussed here.

[otaviof]

/cc @ricardomaraschini

[gabemontero]

In #68, the proposal is for Shipwright to have native triggering support for BuildRuns. Out of the gate the proposal supports the following:

* GitHub

* Tekton Pipelines (between and within pipelines)

* Image changes

It is clear from the discussion that we will need to go beyond these and have more general-purpose mechanisms for adding triggers. See the suggestions for ArgoCD Workflows (#68 (comment)) and CD Events (#72).

Let's discuss:

1. What things would you like to trigger a Shipwright BuildRun?

All of your above items conceivably @adambkaplan

2. What things would you like to trigger after a Shipwright BuildRun completes?

I'm not sure I even know what the comprehensive list might be yet, but minimally, just borrowing from openshift builds, and converting apples to oranges:

• scale up / scale down k8s deployments et. al. that use the image a buildrun produces
• rollout k8s deployments et. al. that use the image a buildrun produces
• another buildrun
• a tekton pipelinerun / taskrun

[lizzzcai]

I will expect to trigger a BuildRun by GitHub action (monitoring a specified branch) as I would like to build my image once the code changes, Argo workflow (or similar pipeline, taskrun) as I would like to trigger a build by another custom process.

For a finish of a buildrun, it can trigger another buildrun (support parallel), or it can trigger a create of another custom resources (like knative serving, should be able to pass parameters like image path to the CR). So I can have a full pipeline: github code changes -> buildrun (new image) -> knative serving(provide service)

[SaschaSchwarze0]

I like the idea to take a BuildRun as a trigger. Or more specific, a BuildRun of a specific Build.

Scenario imo mostly applies to Dockerfile-strategy-based Builds where I want to trigger a Build that uses image a FROM image that is built by a different Build. It should be the consuming build to define that it gets triggered by the "prereq" Build.

There is an overlap with the Image trigger. So, if we eventually are ready to push to an Image instead of only directly to a registry, then the same problem could also be solved like this. But, I think that is fine. Those who work without the Image component have then still a way to automatically rebuild and image.

--

What is getting clear to me, is that the Image component will then become a component that does not only manage the images that are supposed to run in the Kubernetes cluster itself, but also those that are used as base images in image builds. Otherwise it cannot be used as a trigger. This would then cover both FROM images in Dockerfile builds, or base images in Dockerfile-less builds, like what is specified in a .ko.yaml, or the run image of a Buildpacks stack.

[otaviof]

I like the idea to take a BuildRun as a trigger. Or more specific, a BuildRun of a specific Build.

Scenario imo mostly applies to Dockerfile-strategy-based Builds where I want to trigger a Build that uses image a FROM image that is built by a different Build. It should be the consuming build to define that it gets triggered by the "prereq" Build.

That's an interesting use-case, Sascha. I initially thought to use the Image controller to trigger builds based on the FROM image, but indeed, it should also support watching BuildRun (for a given Build).

Would you please open a issue on the Triggers repository? We should aim for this in a future milestone.

[SaschaSchwarze0]

Done, shipwright-io/triggers#3

[SaschaSchwarze0]

Another thing that just comes to my mind. As of today, we also have triggers, no, we have a single trigger: the manual one where a human creates the BuildRun. I am wondering if there might be the scenario where I want to define a Build that can only get triggered from an event, but want to prevent it to be manually triggered.