[WIP] Add continuous integration models (Projects and Builds)

[eddycharly]

Changes

This PR adds continuous integration models to the dashboard.
It does so by adding two new CRDs Projects and Builds.
Those two new resources help bootstrapping the triggers and pipelines resources to setup continuous integration with pipeline definitions stored in the target repository.

A Project will setup:

• an EventListener to receive github webhooks
• a TriggerBinding to bind properties from the incoming webhook
• a TriggerTemplate to create a TaskRun that will clone the repository read the pipeline definition file and instantiate a Build
• an Ingress pointing the event listener service

A Build will setup:

• a PipelineRun implementing the pipeline definition that came from the repo

All those resources are correctly meshed together through owner references, they are reconciled and have statuses that aggregate the statuses from the resources they are responsible for.

I will make a demo on next WG meeting, i opened the PR if someone wants to give a look or try it out before Monday.

/cc @AlanGreene @a-roberts

A few screenshots:

Projects list

Builds list

Create project form

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices

See the contribution guide
for more details.

[tekton-robot]

@eddycharly: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[afrittoli]

This feels like something that would be a good candidate for a TEP @vdemeester @bobcatfish @wlynch

[wlynch]

This feels like something that would be a good candidate for a TEP @vdemeester @bobcatfish @wlynch

Agreed! This sounds similar to our ideas around generators. See https://github.com/tektoncd/experimental/tree/master/generators for some work we're doing in this space.

[a-roberts]

Big +1 on this being a TEP and thanks for sharing @wlynch! As I said on the working group call today, it seems it's a sought-after feature in some way, shape, or form, and having the abstraction makes a late of sense.

@eddycharly what do you think, perhaps we'd extend the dashboard to show the abstractions that do became part of the TEP, or your projects/builds become yours?

Full disclosure, I used to work on a Kubernetes offering called Microclimate and we used the exact same terminology (we actually had CRDs), and that worked really well... unfortunately we didn't open-source that, but if you would like to know more please let me know and I'm sure we can make something awesome for the community to benefit from.

[afrittoli]

One vague concern I have about this is that Tekton has been this far rather non-opinionated about how you setup you CI/CD pipelines. I'm a bit wary of taking a direction away from that.
On the plus side, giving our users a way kick-start a CI is probably a good idea :)

[a-roberts]

One vague concern I have about this is that Tekton has been this far rather non-opinionated about how you setup you CI/CD pipelines. I'm a bit wary of taking a direction away from that.
On the plus side, giving our users a way kick-start a CI is probably a good idea :)

Good point, that's why the webhooks extension was an experimental thing really and was quite opinionated and limited in the type of pipelines you run - I think that may be the biggest thinking point actually...

[eddycharly]

Thanks for your feedback.

I’ve eared very little about the generators project but if I understand correctly it’s supposed to simplify writing pipelines. If so it would be complementary and allow to write CI spec in a simplified syntax (something like travis ?).

Regarding the TEP suggestion, why not, it doesn’t have to be bound to the dashboard. In the end it’s just two new resource types and controllers.

It was easy to start in the dashboard repo but it can be extracted very easily.

What would be nice would be to be able to create Builds directly using a trigger template instead of going through a task run just for that. Any plan to support arbitrary resources in trigger templates ?

[AlanGreene]

I like the idea of keeping the core dashboard non-opinionated. It was originally envisioned as a Tekton analog of the Kubernetes dashboard, presenting a view of the live state of Tekton resources in the cluster. Developing a UI for a full CI/CD solution has a different set of design considerations as it needs to solve some very different problems.

The current prototype should work well as a dashboard extension.

A topic we've discussed a few times is making extensions more powerful, for example allowing them not only to add new pages to the dashboard, but also to allow them to integrate into / customise core pages. This wouldn't be needed for the current prototype but could open up some interesting possibilities.

[AlanGreene]

Any plan to support arbitrary resources in trigger templates ?

This has been raised a few times, see for example tektoncd/triggers#482 and some of the other issues linked to it.

[bobcatfish]

One vague concern I have about this is that Tekton has been this far rather non-opinionated about how you setup you CI/CD pipelines. I'm a bit wary of taking a direction away from that.
On the plus side, giving our users a way kick-start a CI is probably a good idea :)

My dream would be to have a solution that captures both: or at least if the abstractions are more opinionated, at least have them be optional.

I think getting a proposal that we're all happy with will probably take a while and there will be a lot to consider but I'd love to see the discussion get started!! If dashboard wants to go ahead with something in the meantime I could see that working too, as long as it's something that could be changed later if we create tekton-wide abstractions.

@a-roberts @eddycharly do you think someone working on this feature would be able to give us an overview in the API working group one day soon?

[wlynch]

I’ve eared very little about the generators project but if I understand correctly it’s supposed to simplify writing pipelines. If so it would be complementary and allow to write CI spec in a simplified syntax (something like travis ?).

Not only pipelines, but all related resources (e.g. Triggers). The reason why we wanted to do this is for the same motivation as your reason for the Project CRD - to help users bootstrap integration specific resources for CI.

What would be nice would be to be able to create Builds directly using a trigger template instead of going through a task run just for that. Any plan to support arbitrary resources in trigger templates ?

There's no technical limitation for creating other resources as a part of trigger templates. My understanding is that we restricted it because we were worried about the potential for abuse for creating arbitrary k8s resources. You can allow new clientsets using: https://github.com/tektoncd/triggers/tree/master/pkg/client/dynamic/clientset (see https://github.com/tektoncd/triggers/blob/d51f0f43612b394e2327bdabeeee020457b62f2d/cmd/eventlistenersink/main.go#L61 for how this is used).

Another option is reconsidering the GVK restriction altogether and just trust EventListener service account RBAC roles to be a sufficient perimeter. /cc @gabemontero

a TriggerTemplate to create a TaskRun that will clone the repository read the pipeline definition file and instantiate a Build

This sounds like config as code! This is a problem we want to solve for Tasks/Pipelines in general.
See tektoncd/pipeline#2298, tektoncd/triggers#189

A Build will setup: a PipelineRun implementing the pipeline definition that came from the repo

Instead of defining a new wrapper type, my general preference would be to stick with PipelineRuns and solve the underlying root problem of config as code pipelines (since we know this is something we want to support for Pipeline/TaskRuns in general).

This may benefit from Pipeline in Pipelines via Custom Tasks - https://github.com/tektoncd/community/blob/master/teps/0002-custom-tasks.md

One vague concern I have about this is that Tekton has been this far rather non-opinionated about how you setup you CI/CD pipelines. I'm a bit wary of taking a direction away from that.

+1. One thing we wanted to be careful about in Generators was to not make things GitHub specific (or even within GitHub, how can I configure OAuth vs GitHub Apps?)

[eddycharly]

@bobcatfish i will try to join on next monday. no guarantee though as i'll be on vacation.

[eddycharly]

This sounds like config as code! This is a problem we want to solve for Tasks/Pipelines in general.

Exactly, in-repo config, that was one of the most important point to address for me. Build strategy can be different from one branch to another and it should be the devs responsibility.

+1. One thing we wanted to be careful about in Generators was to not make things GitHub specific (or even within GitHub, how can I configure OAuth vs GitHub Apps?)

Same here, a Project only represents the tunnel to stimulate a build from an event coming from the outside world. A Build connects a resource generated from the event with a pipeline that know how to process this event (the event can come from github, gitlab, curl, anything...). Right now the dashboard only supports GitHub in the UI but you can create whatever you want in yaml.

Instead of defining a new wrapper type, my general preference would be to stick with PipelineRuns and solve the underlying root problem of config as code pipelines (since we know this is something we want to support for Pipeline/TaskRuns in general).

I tend to disagree on this one, having a wrapping type allows to add features like decorating pull requests, notifications, etc... easily. Those things do not really need to work with raw pipelineruns. It also allows easy aggregations/filtering (like filtering builds for a particular repo/branch).

One vague concern I have about this is that Tekton has been this far rather non-opinionated about how you setup you CI/CD pipelines. I'm a bit wary of taking a direction away from that.
On the plus side, giving our users a way kick-start a CI is probably a good idea :)

I completely agree and understand this position. IMO it's not a vague concern but an essential point though.
Bottom line, this is a product decision. I see good reasons why Tekton has to stay non-opinionated but hopefully someone will build a product from it.

[wlynch]

It also allows easy aggregations/filtering (like filtering builds for a particular repo/branch).

You might be interested in tektoncd/community#147! I recently proposed this to define how we can better annotate this type of data in Task/PipelineRuns.

[eddycharly]

Interesting ! It looks like Task/PipelineRuns are getting responsible of a lot of things though.

I like the idea of a more high level resource used to federate smaller resources that address a single responsibility.

[bobcatfish]

@eddycharly no hurry at all! vacations are important, plz don't feel any pressure to join, happy to wait till you're back :)

[eddycharly]

@bobcatfish no pressure at all, I’ll join if I can don’t worry ;)

[gabemontero]

I’ve eared very little about the generators project but if I understand correctly it’s supposed to simplify writing pipelines. If so it would be complementary and allow to write CI spec in a simplified syntax (something like travis ?).

Not only pipelines, but all related resources (e.g. Triggers). The reason why we wanted to do this is for the same motivation as your reason for the Project CRD - to help users bootstrap integration specific resources for CI.

What would be nice would be to be able to create Builds directly using a trigger template instead of going through a task run just for that. Any plan to support arbitrary resources in trigger templates ?

There's no technical limitation for creating other resources as a part of trigger templates. My understanding is that we restricted it because we were worried about the potential for abuse for creating arbitrary k8s resources. You can allow new clientsets using: https://github.com/tektoncd/triggers/tree/master/pkg/client/dynamic/clientset (see https://github.com/tektoncd/triggers/blob/d51f0f43612b394e2327bdabeeee020457b62f2d/cmd/eventlistenersink/main.go#L61 for how this is used).

Another option is reconsidering the GVK restriction altogether and just trust EventListener service account RBAC roles to be a sufficient perimeter. /cc @gabemontero

Apologies for the delay (did not get to this before stepping away from work a little over a week ago).

If we were to fall back / depend on service account RBAC, in addition to the EventListener's, I would also suggest the current Trigger SA association, as well as whatever falls out from the Multi Tenant EventListener and new Trigger CRD should also be considered as the authenticated party in object creation. Generally speaking, providing options wrt granularity (i.e. different controllers or different api server clients) on who can create whatever objects would be preferable.

a TriggerTemplate to create a TaskRun that will clone the repository read the pipeline definition file and instantiate a Build

This sounds like config as code! This is a problem we want to solve for Tasks/Pipelines in general.
See tektoncd/pipeline#2298, tektoncd/triggers#189

A Build will setup: a PipelineRun implementing the pipeline definition that came from the repo

Instead of defining a new wrapper type, my general preference would be to stick with PipelineRuns and solve the underlying root problem of config as code pipelines (since we know this is something we want to support for Pipeline/TaskRuns in general).

This may benefit from Pipeline in Pipelines via Custom Tasks - https://github.com/tektoncd/community/blob/master/teps/0002-custom-tasks.md

One vague concern I have about this is that Tekton has been this far rather non-opinionated about how you setup you CI/CD pipelines. I'm a bit wary of taking a direction away from that.

+1. One thing we wanted to be careful about in Generators was to not make things GitHub specific (or even within GitHub, how can I configure OAuth vs GitHub Apps?)

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign eddycharly
You can assign the PR to them by writing /assign @eddycharly in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tekton-robot]

@eddycharly: The following tests failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
pull-tekton-dashboard-unit-tests	b7a5a2f	link	/test tekton-dashboard-unit-tests
pull-tekton-dashboard-build-tests	ac6cc61	link	/test pull-tekton-dashboard-build-tests
pull-tekton-dashboard-integration-0-13-2-tests	ac6cc61	link	/test pull-tekton-dashboard-integration-0-13-2-tests

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[AlanGreene]

Closing as discussed on recent Dashboard WG calls since this feature doesn't make sense as part of the core Dashboard application.

This is still very useful and could be implemented as an extension or combined with the generators experimental project or other related efforts.