Prow support for triggering jobs based on tag changes

[perotinus]

It would be useful to the cluster-registry if Prow could support triggering jobs based on GitHub CreateEvent"s.

Concrete use case: I would like to be able to do cluster-registry releases without having to run tools locally on my machine, based on tags created by a GitHub release. If Prow can respond to GitHub CreateEvents, then creating the tag can run the release process/upload binaries/etc. without requiring the person. This allows releases to be done by people who may not have write access to the GCP project that hosts the binaries, simply by creating a

Subnote: it might be useful to know if a tag is verified, and to only start a release based on a verified, signed tag. cf https://help.github.com/articles/signing-tags-using-gpg/

[BenTheElder]

Also CC @Kargakis @stevekuznetsov @sebastienvas for potentially interested parties.

As discussed on slack probably the most tricky part to supporting tag-triggered-jobs is deciding how we want the config to look.

I'm not sure about the GPG checking details wit github but this also sounds potentially useful

/area prow
/kind feature

[stevekuznetsov]

If we want to use these jobs for building and pushing releases we should probably get a trusted build cluster up and running otherwise your ProwJob running on a new tag won't have the credentials to do anything meaningful with whatever it builds.

[BenTheElder]

Yeah, it would be preferable to have #5848 first. We definitely plan to implement that one though.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[BenTheElder]

/remove-lifecycle stale

[cjwagner]

Triggering jobs as a result of tags is something that sig-service-catalog is trying to do.
@n3wscott

[BenTheElder]

this sort of thing would be a lot more straightforward to add if we decoupled job definitions and triggering
cc @stevekuznetsov @krzyzacy

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[BenTheElder]

/remove-lifecycle rotten

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta]

Note that you can create a sequence of activity based on merge events, which we do in order to have prow update itself: https://testgrid.k8s.io/sig-testing-prow

1. postsubmit job to build and push all images on each commit
2. periodic job to create a new PR that upgrades the committed resources' image tags to the latest release from (1)
3. postsubmit job to deploy the committed resources to kubernetes each commit (which will apply the specified change during (2)

[BenTheElder]

this would be nice to have for github releases though to further automate publishing of tagged/named release versions, the main reason we can't implement this is how cludgey the triggering logic is now :(

this should basically just be a post-submit triggered on tags being pushed.

/remove-lifecycle rotten

[BenTheElder]

see this thread: #10802 (comment)

[cjwagner]

So we already (inadvertently) support triggering jobs based on tag changes by using a postsubmit job with a branch regexp matching refs/tags/<tag-name>?
That is an interesting find and a pleasant surprise. I think that means we can close this issue.

[zhouhaibing089]

So we already (inadvertently) support triggering jobs based on tag changes by using a postsubmit job with a branch regexp matching refs/tags/?

I think refs/tags/ is trimmed in this change