Add Git-Based Versioning for Tekton Packages

Is your feature request related to a problem? Please describe. Today Tekton catalog follows directory-based versioning structure, where each version of the resource is located in a dedicated folder like /task/argocd/0.1/argocd.yaml.

The Tekton community is working on add git-based versioning to Tekton catalog, where directories - 0.1...0.n will be removed, and versioning will be supported via git tags (i.e. the tags in the catalog repo will map to versions in the Hub e.g. tag “v0.7” in a Catalog maps to version “0.7” in the Hub).

Currently, Artifact Hub fetches Tekton Task and Pipelines based on the directory-based versioning, we would like to have Artifact Hub to support git-based versioning for Tekton Tasks and Pipelines.

Describe the solution you’d like We would like Artifact Hub to surface all Tekton package versions that follows the git-based versioning as it is in the directory-based versioning today.

As an example, I registered a Tekton package from this repo that follows git-based versioning (with 2 tags: v0.1 and v0.2) . However, only the latest version is detected:

Describe alternatives you’ve considered

Additional context The Tekton community now encourage users to create Catalogs in their own repos and share them through the Hub instead of using a centralized catalog. This is naturally supported in Artifact Hub.

The existing centralized catalog will remain as it is using the directory-based contract. It will be read-only and will encourage owners of the resources to move them to their own repositories in their own GitHub organizations. After 9 months, we will archive the tektoncd/catalog repository. At the same time, we will remove support for the directory-based versioning in the Tekton Hub.

[tegioz]

Done 🙂

[tegioz]

Hi 👋

We’ve just added experimental support for git based versioning for Tekton packages (#2337). You can see it in action in the staging environment (we added the repo you shared above @QuanZhang-William). We can now continue iterating over this first implementation 🙂

When adding a Tekton tasks or pipelines repository, you can now select what versioning model applies to it (to keep backwards compatibility with existing repos):

There are a couple of points I’d like to mention:

• Versions: at the moment the version in the tag file must match the one in the manifest file. If you’d like a different behavior please let us know. In catalogs with a lot of packages, this may require a bit of work I guess, touching quite a few manifest files every time a bump is needed. Maybe you plan to eventually remove the version in the manifest, not sure (from: Versioning will move from the resources themselves to the Catalog as a whole).

• This one is also related to versions. In Artifact Hub, every package (a task or pipeline in this case) must have a version. Given that all tasks in a catalog will share the same version, I understand that sometimes the version for a task will be bumped even though that particular task may not have changed at all. Users in Artifact Hub can subscribe to new releases notifications and, in cases like the one just mentioned, they may be notified about a new package release when nothing actually changed, which could be a bit annoying for users. I’ve already discussed this concern with @QuanZhang-William in Slack, and he mentioned that you were moving to smaller repos with fewer (or even one) packages per repo, which would definitely help.

When you have a chance please give it a try on staging and let us know your thoughts 🙂