Automated release for tektoncd projects

[vdemeester]

It should be possible for any projects in the tektoncd umbrella to do release without having to access the prow “production” cluster. Owner from a project should be able to create a release branch, maybe configure prow to build that release (ideally it would be automated) and it should just works.

As of today, tektoncd/pipeline and tektoncd/cli releases are done manually, accessing the prow “production” cluster.

Design docs is here

/area prow /kind feature

[afrittoli]

Nightly releases are available now for pipeline and dashboard. Full releases are automated, but the preparation and trigger is still manual and require access to the cluster.

Major releases (from master)

Trigger is the creation of a branch named release-vX.Y.Z.

• The trigger extracts the version name and sha from the github event
• A release is triggered, same as for nightly releases
• Upon successful completion, the github helper pipeline is triggered
• A draft release, with name TBD, is created in GitHub
• The release captain edits the release notes and name of the release, and publishes it, triggering the creation of a new tag

Minor releases (from branches)

Trigger is a weekly job, that searches for all branches named release-vX.Y.Z.

• For each branch
• if there are commits after the last tag on the branch, trigger a release
• store the release under //<new-tag=last-tag+0.0.1>
• Upon successful completion, the github helper pipeline is triggered
• A draft release, with name TBD, is created in GitHub
• The release captain edits the release notes and name of the release, and publishes it, triggering the creation of a new tag

[tekton-robot]

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.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

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.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

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.

[vdemeester]

/remove-lifecycle rotten /remove-lifecycle stale /reopen

[tekton-robot]

@vdemeester: Reopened this issue.

In response to this:

/remove-lifecycle rotten /remove-lifecycle stale /reopen

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.

[tekton-robot]

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.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[vdemeester]

/remove-lifecycle stale

[tekton-robot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten with a justification. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[chmouel]

/remove-lifecycle stale

[tekton-robot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen with a justification. Mark the issue as fresh with /remove-lifecycle rotten with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen with a justification. Mark the issue as fresh with /remove-lifecycle rotten with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

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.

[vdemeester]

/reopen /lifecycle frozen I still want for project to be able to release in an automated way 👼🏼

[tekton-robot]

@vdemeester: Reopened this issue.

In response to this:

/reopen /lifecycle frozen I still want for project to be able to release in an automated way 👼🏼

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.

[jerop]

/assign

[afrittoli]

@jerop do you still on working on this?

[jerop]

@afrittoli haven't had a chance to do this, will unassign myself

[afrittoli]

The main inputs to a release are:

• The release name
  • This is in the format "Cat breed, robot name"
  • The name is the same for minor releases
  • It could be automated based on a dictionary of names
• The release version
  • Using semantic versioning vX.Y.Z
  • X == 0 for now
  • Y is the main release number
  • Z is for patch releases done in case of regressions / security patches
  • the input here could be which digit we want to increase, but it's probably easier to get the full version as input
  • we should validate whether the new version number is valid, i.e. we are not skipping a number on any of X, Y or Z
• The git sha.
  • If we created a branch first, this could be derived from the release version.

Other inputs that we can calculate:

• the old release
  • this can be derived from the new release number
  • if it's a minor release, use minor -1. If it's a major release, use the last release available
• wether to release as latest
  • in case of major release, yes
  • in case of minor release, only if it's a minor on the latest release
• the Rekor UUID
  • We can get this using the rekor CLI or perhaps the annotation on the taskrun

Other inputs that we cannot calculate:

• Release tag line
• Min k8s version
• Deprecation notices
• Backward incompatible changes
• Upgrade notices

For all these inputs we could perhaps host a file in the repo, so that the information is also available outside of the rendered release notes?

[afrittoli]

I think we could break this down into the following items:

• [ ] Deploy full release resources to a dedicated namespace with access to the tekton-releases account
• [ ] Create tektoncd/triggers resources that react to an event which includes the required inputs
• [x] Remove PipelineResources from the create-draft-release task (it will be a pipeline)
• [x] Extend create-draft-release to include discovering the Rekor UUID and validating the release
• [ ] Automate the execution of create-draft-release on completion, signature and attestation of a release
• [ ] Design a front end for triggering the releases, that only authorised individuals can use. Ideas could be: webhook from create a branch / tag, use a k8s job that sends an event, create a script that sends an event , slack command, some GitHub event (Issue with special format, Milestone or else)
• [ ] Automate follow-up on release-publish events:
  • [ ] Create README update PR
  • [ ] Create website sync config PR
  • [ ] Send notification on slack

[vdemeester]

I think we may want to allow each project to decide a bit how they want to do their release (aka required inputs, …). We are going to try working towards this for tektoncd/cli and tektoncd/operator. The general idea is the following:

• we use a github action to "trigger" the release (that way, any owner can create an action that will send a custom payload to an eventlistener on dogfooding.
  • That workflow can also run weekly to automatically do bugfix releases.
  • That workflow is configured with the correct secret to send to the eventlistener
  • Later on we can think of having the same through slack, …
  • Inspiration for this (action, tooling) is from knative org (actions and test-infra repositories)
• the "resource" triggered runs the release pipeline from the project
  • the source of truth for the pipeline/task has to be in the to-be-released repository
  • most likely using kustomize to import tasks, pipelines, … from plubming, catalog, …

[vdemeester]

/area roadmap