[workflows] POC using flux

[lbernick]

Based on https://bigkevmcd.github.io/tekton/flux/notifications/2020/12/06/flux-tekton.html. Uses Flux GitRepositories to poll for changes to specific branches on linked repos, Flux Receivers to accept events related to changes to these GitRepositories, a Flux Provider to turn a Tekton EventListener into a Flux event sink, and a Flux Alert to connect notifications related to the GitRepositories to the Provider that forwards to the EventListener. (There may be a simpler way to do this!)

This modifies the workflows API to allow multiple event types per event source, as this maps more easily to flux event types, and avoids having to duplicate the same repo just to allow triggering on multiple event types. Each workflow Trigger's webhook secret is passed to the github receiver.

Benefits:

• don't have to implement connections to git providers

Challenges:

• Flux bootstrapping requires providing credentials to allow Flux to create a repo in your git provider org
• Flux GitRepository is meant to watch changes to a branch, so it's not well suited for CI, and it accepts only a branch name rather than a regex that could be a branch, tag, or commit
• CEL filters now need to be rewritten in terms of the Flux event body instead of an event body from Github or elsewhere.
• I'm not aware of a way to use informers/listers with Flux objects.
• (maybe) some Flux objects may need to live in the "flux-system" namespace, so they cannot have the workflow as their owner ref

Potential challenge or benefit:

• Flux GitRepository polls for changes to the GitRepository, so it takes some time to generate a notification after a change, but it doesn't require creating an ingress for a webhook.

Submitter Checklist

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

• Includes docs (if user facing)
• Commit messages follow commit message best practices
• Commit messages includes a project tag in the subject - e.g. [OCI], [hub], [results], [task-loops]

See the contribution guide
for more details.

[tekton-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from lbernick after the PR has been reviewed.

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

Needs approval from an approver in each of these files:

• workflows/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]

@lbernick: 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.