-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TEP-0115] Support Artifact Hub in Hub Resolver #5666
[TEP-0115] Support Artifact Hub in Hub Resolver #5666
Conversation
Skipping CI for Draft Pull Request. |
/kind feature |
/test all |
The following is the coverage report on the affected files.
|
4200449
to
9533601
Compare
/test all |
The following is the coverage report on the affected files.
|
9533601
to
153e4fa
Compare
/test all |
The following is the coverage report on the affected files.
|
Nice! |
153e4fa
to
8d566f0
Compare
/retest |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
8d566f0
to
ee29374
Compare
The following is the coverage report on the affected files.
|
/retest |
00d375d
to
f62bac5
Compare
The following is the coverage report on the affected files.
|
f62bac5
to
e368375
Compare
The following is the coverage report on the affected files.
|
/retest |
known flake: #4643 /retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @QuanZhang-William !! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
resVer := version | ||
|
||
if hubType == ArtifactHubType && len(semVer) == 2 { | ||
resVer = version + ".0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit concerned about doing this - i.e. if someone takes this version and tries to fetch the config, will this guarantee to always work? i.e. if artifacthub publishes 0.1
, will I always be able to fetch 0.1.0
and will this always map to 0.1
? Or could a different 0.1.0
be added after?
There's an argument that maybe the resolver shouldn't try to interpret semver and just always handle versions as-is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @wlynch, thanks for your input and this is a good question 😀 . The short answer is yes. If artifacthub publishes 0.1, and I will always be able to fetch 0.1.0
The artifact hub will always convert the resource yaml version to semVer (i.e. 0.6
-> 0.6.0
) and the Hub uses the semVer to index the corresponding resource.
So technically you can publish a resource with yaml version 0.6
first (which is converted to 0.6.0
in the Hub), and then publish another yaml version of 0.6.0
, it just overrides the previous 0.6.0
version in the Hub. But the API will always return the latest 0.6.0
The main reason I put such conversion is for backward compatibility, so that current users can keep version 0.6 in the resolver, and the type is default to artifact
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd lean towards dropping this for the new artifacthub impl:
- semver with a missing minor/patch version generally uses the latest version matching the prefix (i.e. the golang 1.19 docker image refers to the latest patch version 1.19.2) - I'm not sure we want to have the resolver implement this kind of lookup behavior.
- I'm worried about version skew for ArtifactHub URLs - e.g. https://artifacthub.io/packages/tekton-task/tekton-catalog-tasks/git-clone/0.8.0 (even though this points to the 0.8 git tag), but https://artifacthub.io/packages/tekton-task/tekton-catalog-tasks/git-clone/0.8 404s.
It'll probably be simpler long term for the resolver to interpret the user provided version tag as-is, so it always matches the upstream state (up to you if you want to preserve the old behavior for compatibility).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Artifact Hub always converts the resource yaml version and git tag to semVer here (by appending 0 as minor and patch version if missing) and requires the exact match between the 2 after conversion.
For 2, I don't think there is version skew for the Artifact Hub URL since all the valid URLs will use semVer no matter how do you tag the repo, and URLs with simple semver will always return 404s.
Because the resource is indexed by the resource yaml version, we cannot use the latest version matching the prefix logic here (so we can only append 0s).
So it seems to me that the lookup here brings the extra backward compatibility benefit and does not cause any problems (i.e. version 0.6
and version 0.6.0
in the hub resolver always points to the same resource)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts? @jerop @abayer @vdemeester?
e368375
to
4a3f5e4
Compare
The following is the coverage report on the affected files.
|
Part of [issues/667]. This commit adds support to resolve catalog resource from the [Artifact Hub] while keeping current functionality of fetching resources from Tekton Hub. - Change 1: The commit adds a new field `type` to the hub resolver indicating the type of the Hub to pull the resource from. The value can be set to `tekton` or `artifact`. By default, the resolver fetches resources from `https://artifacthub.io/` when setting `type` to `" artifact"`, and fetches resources from user's private instance of Tekton Hub when setting `type` to `"tekton"`. - Change 2: Prior to this change, the hub resolver only supports pulling resources from the Tekton Hub. This commit updates the default hub type to `artifact` since the [Artifact Hub][Artifact Hub] will be the main entrypoint for Tekton Catalogs in the future. - Change 3: Prior to this change, the default Tekton Hub URL is: `https://api.hub.tekton.dev`. This commit removes the default value of the Tekton Hub URL and enforces users to configure their own instance of Tekton Hub since the public instance `https://api.hub.tekton.dev` will be deprecated after the migration to Artifact Hub is done. /kind feature [Artifact Hub]: https://artifacthub.io/ [issues/667]: tektoncd/hub#667
4a3f5e4
to
dda9d0d
Compare
The following is the coverage report on the affected files.
|
/approve cc @abayer |
Would it be worth adding docs around configuring the different hub impls and the differences between them? |
Hi @wlynch, I have some documentation here talking about the configuration and migration to the Artifact Hub. Is there thing else you suggest to add? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My mistake!
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jerop, wlynch The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Changes
Part of issues/667.
This commit adds support to resolve catalog from the Artifact Hub and keep current functionality of fetching catalog from the Tekton Hub.
The commit adds a new field
type
to the hub resolver indicating the type of the Hub to pull the resource from. The value can be set totekton
orartifact
. By default, the resolver fetches resources fromhttps://artifacthub.io/
when settingtype
toartifact
.Prior to this change, the hub resolver only supports pulling resources from the Tekton Hub. This commit updates the default hub type to
artifact
since the Artifact Hub will be the main entrypoint for Tekton Catalogs in the future.Prior to this change, the default Tekton Hub URL is:
https://api.hub.tekton.dev
. This commit removes the default value of the Tekton Hub URL and enforces users to configure their own instance of Tekton Hub since the public instancehttps://api.hub.tekton.dev
will be deprecated after the migration to Artifact Hub is done./kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes