search

tektoncd / catalog

Catalog of shared Tasks and Pipelines.
Apache License 2.0
662 stars 576 forks source link

`v1` support and the future of `tektoncd/catalog` #1146

Open vdemeester opened 1 year ago

vdemeester commented 1 year ago

This issue is to discuss and track work around having v1 API support for tasks in the catalog, in the light of the recent TEP around catalog:

As of tektoncd/pipeline latest LTS release (0.44.x), we provide v1 API for tekton pipeline's objects. This means, we can start publishing Tasks using v1. But as TEP-0079 state, we want to move towards having smaller, well written and supported Tasks (and other resource) maintained, in the tektoncd-catalog org. And let contributors share and maintain resources in their own Community Catalogs. Hence this issue.

  1. All the task that are migrating to a tektoncd-catalog repository will switch to v1 there and marked as deprecated here.
  2. For the rest of Task, we probably want to notify OWNERS and/or adopt those in our own set of catalog (our meaning "individuals" or " companies").
  3. What deadline do we set for marking this repository as deprecated as well ?

/cc @tektoncd/catalog-maintainers @tektoncd/catalog-collaborators @QuanZhang-William @bobcatfish @jerop

QuanZhang-William commented 1 year ago

Thanks @vdemeester! For 1, taking the example of golang catalog migration, the current selection of the resources to be migrated is in v1beta1, and we planned to version it as v1.0.0 in the new catalog.

If we want to bump the API version to v1, do we directly make the change in the v1.0.0 release of the catalog or creating a new patch version like v1.0.1?

vinamra28 commented 1 year ago

yes @QuanZhang-William, we should be bumping up the version of the resource

vdemeester commented 1 year ago

@QuanZhang-William I think it really depends on what we want to support. We could state that anything going in tektoncd-catalog is going to be v1 only and we could start v1.0.0 with that. Otherwise, we would still need to bump more than just a patch version (as it's using a new API).

QuanZhang-William commented 1 year ago

@QuanZhang-William I think it really depends on what we want to support. We could state that anything going in tektoncd-catalog is going to be v1 only and we could start v1.0.0 with that. Otherwise, we would still need to bump more than just a patch version (as it's using a new API).

Agreed. I think the question is that do we want to continue to maintain v1beta1 resources in the verified catalogs. If we don't plan to make changes to v1beta1 resources in the verified catalogs, I think it makes more sense to directly start with v1 since the v1beta1 resources are still available to users in the old central catalog even though it will be archived soon.

Supporting both v1beta1 and v1 resources also doubles the maintenance cost. For the git-clone example: if we support both API versions, we need to migrate git-clone v0.6 - v0.9 in the old catalog (using v1beta1 API version) to v1.0.0 to v4.0.0 in the new catalog, then bump the API version to v1 and continue to create catalog release v5.0.0 to v8.0.0? This sounds a bit weird to me.

WDYT?

/cc @ywluogg

QuanZhang-William commented 1 year ago

Catalog WG summary: The verified catalogs will be started with v1 api version. tektoncd/catalog will continue to use v1beta1 api version.

tekton-robot commented 1 year ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. 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 with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

tekton-robot commented 1 year ago

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.

vdemeester commented 1 year ago

/lifecycle frozen