Skip to content
This repository has been archived by the owner on Sep 5, 2019. It is now read-only.

Proposal: Knative Build deprecation in favor of Tekton Pipelines #614

Closed
vdemeester opened this issue Jun 4, 2019 · 5 comments · Fixed by #655
Closed

Proposal: Knative Build deprecation in favor of Tekton Pipelines #614

vdemeester opened this issue Jun 4, 2019 · 5 comments · Fixed by #655

Comments

@vdemeester
Copy link
Member

vdemeester commented Jun 4, 2019

Objective

Propose to mark knative/build as deprecated and drive user to the Tekton project as their building engine. This doc should be used as a forum for external comment and questions, to resolve any concerns before the Steering Committee decides whether to adopt the proposal.

Background

Starting with v1beta1 API of knative (serving), the embedded build feature will be removed from the Knative Service definition, see the proposal here.
This removes Serving optional dependency on Knative Build, making Knative Build fully decoupled from the rest of the Knative components and only responsible to build images that will be using in services later on. This responsability is shared with any projects capable of building images in Kubernetes.

The Tekton Pipeline (https://github.com/tektoncd/pipeline) project originates from Knative project (was knative/build-pipeline) and is enhancing Knative Build functionality, providing advanced CI/CD features on top of the base that Knative laid.

The Tekton Pipeline's Task and TaskRun objects are mapping Knative's Build and BuildTemplate object, making the migration from Knative Build to Tekton Pipelines easy. This migration steps should be documented in the near future.

The Tekton Catalog project (https://github.com/tektoncd/catalog) aims to provides a catalog of re-usable task, similar to what Knative BuildTemplate repository is doing today (https://github.com/knative/build-template)

In this catalog, there is an on-going effort to provide tasks to easily deploy and interact with Knative services (tektoncd/catalog#36). This effort aims to make it easy for user to move from Serving v1alpha1 API to v1beta1 by using Tekton Pipeline Tasks to deploy their services.

User are getting confused whether the should use Knative Build or Tekton Pipeline (see #606). Deprecating Knative Build would resolve this confusion as it would make it clear that the "building the service(s) image" part is not Knative's responsability and user can use whatever tools is capable of doing that — preferably Tekton Pipelines 👼.

Proposal

The end-state for the Knative Build repository (knative/build) will be to archived in place. However this will happen slowly as we transition through our deprecation plan:

  • A migration guide will be provided for existing Knative Build users to move to TektonCD. This guide will be published in the Tekton documentation. You can read a draft of this guide today.
  • The Knative Build repository (knative/build) will be marked as deprecated, in the README. After the 0.7 cut, Build will no longer be released with the regular Knative releases. However, we may still receive bug and security fixes until officially archived.
  • As Knative reaches v1.0.0, the Knative Build repository (knative/build) will be archived. It will become read-only in GitHub, and no updates, commits, issues or pull-requests will be allowed.

/cc @pmorie @imjasonh
/kind process

@dlorenc
Copy link
Contributor

dlorenc commented Jun 6, 2019

What are the next steps on this proposal?

@vdemeester
Copy link
Member Author

  • Presenting / Discussing it during Knative Build Working Group — done
  • Sending a mail notice on knative-users & knative-dev
  • Knative Steering Commitee presentation and vote
  • Taking the vote into account and doing it (updating the README to mark it as deprecated, update docs, …) and add issues to track migration path and docs in Tekton

@pmorie
Copy link
Member

pmorie commented Jun 11, 2019

At the June 7 meeting of the Steering Committee, there was a desire for this proposal to include more specifics on timelines, eventual fate (archival? deletion?), and any gating factors like availability of a migration guide or features within tekton so that the SC would be in a position of voting on those things as community-driven inputs rather than deciding on them. @vdemeester would you work with the Build WG to expand the proposal in this issue to include that type of information? Once that is done the SC will take another look.

@vdemeester
Copy link
Member Author

Updated the Proposal part to include more specifics

@pmorie
Copy link
Member

pmorie commented Jun 19, 2019

As Knative reaches v1.0.0

Is that Knative serving, specifically? and does this refer to GA rather than literal 1.0 release version?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants