Project proposal: Catalog CR (and cli ext.) in experimental about community HOT 7 CLOSED

/cc @dlorenc @bobcatfish @abayer

from community.

+1000 love the idea.

Question: Is .spec.version a tag/branch/reflike in the repo? How do catalog repo owners express versioning to the CRD?

from community.

+1 from me for the project! v cool :D

I haven't had a chance to review the API in detail so I'm sure (as usual) I'll have opinions but strong 👍 for adding this to experimental :D

from community.

/assign

from community.

👍 from me!

from community.

I forget who I was talking to about this, but what do we think about packaging Tasks/Pipelines/etc. as OCI images in a registry? That gives us a well understood container format (with a reusable library to manage them), a storage scheme (image registries, incl. auth), a naming scheme (image names+tags), content-addressable storage, and even support for sets of them in image indexes.

All we'd need to do is document and build out support for referencing Tasks or Catalogs in configs and the CLI/UI. (e.g., url: gcr.io/tekton-tasks/buildpacks:v0.0.1 or by digest, @sha256:xyz)

from community.

I forget who I was talking to about this, but what do we think about packaging Tasks/Pipelines/etc. as OCI images in a registry? That gives us a well understood container format (with a reusable library to manage them), a storage scheme (image registries, incl. auth), a naming scheme (image names+tags), content-addressable storage, and even support for sets of them in image indexes.

All we'd need to do is document and build out support for referencing Tasks or Catalogs in configs and the CLI/UI. (e.g., url: gcr.io/tekton-tasks/buildpacks:v0.0.1 or by digest, @sha256:xyz)

@imjasonh Right, that's something I had as an early proposal for the catalog. This is something we can explore indeed.

from community.