Add combined remote resolvers binary

[abayer]

Changes

Part of #4710

/kind feature

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs included if any changes are user facing
• Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including
  functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

NONE

[abayer]

/assign @vdemeester @lbernick @jerop @dibyom

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/config/feature_flags.go	81.8%	79.7%	-2.2
pkg/resolution/resolver/bundle/resolver.go	25.0%	50.0%	25.0
pkg/resolution/resolver/framework/configstore.go	30.0%	26.1%	-3.9
pkg/resolution/resolver/git/resolver.go	84.1%	85.9%	1.8
pkg/resolution/resolver/hub/resolver.go	65.0%	70.8%	5.8

[abayer]

/retest

[abayer]

/retest

[vdemeester]

Few comments

• Any reason for not making the bundle resolver disabled (even though it would be enabled by default) ? I think one of the main reason for resolvers is to be able to selectively decide which resolvers are enable and which are not (https://github.com/tektoncd/community/blob/main/teps/0060-remote-resource-resolution.md)
• Naive question : any reason to go for several feature-flags instead of one called enable-resolvers: [] that would take a list of resolvers ? It might be harder to document and validate maybe, but it could be nice as well.

[abayer]

• Any reason for not making the bundle resolver disabled (even though it would be enabled by default) ? I think one of the main reason for resolvers is to be able to selectively decide which resolvers are enable and which are not (https://github.com/tektoncd/community/blob/main/teps/0060-remote-resource-resolution.md)

It's got a feature flag - it's just reusing the existing enable-tekton-oci-bundles one rather than getting a new one.

• Naive question : any reason to go for several feature-flags instead of one called enable-resolvers: [] that would take a list of resolvers ? It might be harder to document and validate maybe, but it could be nice as well.

Good question. I'd lean towards enable-foo-resolver flags rather than a list - not as ergonomic, maybe, but much simpler for users since they don't need to know the exact name of the resolver, they just need to change a flag from false to true. But I'm persuadable. =)

[abayer]

/test check-pr-has-kind-label

[tekton-robot]

@abayer: The specified target(s) for /test were not found.
The following commands are available to trigger required jobs:

• /test pull-tekton-pipeline-alpha-integration-tests
• /test pull-tekton-pipeline-build-tests
• /test pull-tekton-pipeline-integration-tests
• /test tekton-pipeline-unit-tests

The following commands are available to trigger optional jobs:

• /test pull-tekton-pipeline-go-coverage

Use /test all to run all jobs.

In response to this:

/test check-pr-has-kind-label

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[vdemeester]

• Any reason for not making the bundle resolver disabled (even though it would be enabled by default) ? I think one of the main reason for resolvers is to be able to selectively decide which resolvers are enable and which are not (https://github.com/tektoncd/community/blob/main/teps/0060-remote-resource-resolution.md)

It's got a feature flag - it's just reusing the existing enable-tekton-oci-bundles one rather than getting a new one.

• Naive question : any reason to go for several feature-flags instead of one called enable-resolvers: [] that would take a list of resolvers ? It might be harder to document and validate maybe, but it could be nice as well.

Good question. I'd lean towards enable-foo-resolver flags rather than a list - not as ergonomic, maybe, but much simpler for users since they don't need to know the exact name of the resolver, they just need to change a flag from false to true. But I'm persuadable. =)

Fair enough 🙃 then I would lean to add enable-bundle-resolver as enable-tekton-oci-bundles will be deprecated 👼🏼 Just to be more consistent.

Code LGTM 👼🏼
/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester

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:

• OWNERS [vdemeester]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[lbernick]

thanks Andrew! would you mind updating the commit message to say that the hub resolver, git resolver, and bundle resolver are being added, and some detail on the feature flags being used? happy to LGTM once vincent's comment is resolved

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/config/feature_flags.go	81.8%	79.7%	-2.2
pkg/resolution/resolver/bundle/resolver.go	25.0%	50.0%	25.0
pkg/resolution/resolver/framework/configstore.go	30.0%	26.1%	-3.9
pkg/resolution/resolver/git/resolver.go	84.1%	85.9%	1.8
pkg/resolution/resolver/hub/resolver.go	65.0%	70.8%	5.8

[abayer]

@lbernick Done!

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/config/feature_flags.go	81.8%	79.0%	-2.8
pkg/resolution/resolver/bundle/resolver.go	25.0%	50.0%	25.0
pkg/resolution/resolver/framework/configstore.go	30.0%	26.1%	-3.9
pkg/resolution/resolver/git/resolver.go	84.1%	85.9%	1.8
pkg/resolution/resolver/hub/resolver.go	65.0%	70.8%	5.8

[lbernick]

hmm @abayer I thought you fixed the cloud events flake? it's back 😢

[abayer]

/retest

@lbernick It's actually a different flake in the same test. =) The previous ones were duplicate events, this is a more general events-related flake timing out waiting for all the events to be delivered. It popped up sometimes before the duplicate event fix, and I've seen it show up on TestSendKubernetesEvents too. It's less frequent than the duplicate events flakes we used to see on cloud events, at least...

[lbernick]

ah ok sg-- also it looks like your commit message refers to enable-tekton-oci-bundles instead of enable-bundle-resolver

[abayer]

ah ok sg-- also it looks like your commit message refers to enable-tekton-oci-bundles instead of enable-bundle-resolver

Whoops, fixing - enable-tekton-oci-bundles will still work, but yeah, the docs etc should reference enable-bundle-resolver.

[abayer]

@lbernick Fixed, and switched to enable-bundles-resolver since bundles is the resolver value for the resolver, so might as well be consistent.

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/config/feature_flags.go	81.8%	79.0%	-2.8
pkg/resolution/resolver/bundle/resolver.go	25.0%	50.0%	25.0
pkg/resolution/resolver/framework/configstore.go	30.0%	26.1%	-3.9
pkg/resolution/resolver/git/resolver.go	84.1%	85.9%	1.8
pkg/resolution/resolver/hub/resolver.go	65.0%	70.8%	5.8

[abayer]

/retest

[lbernick]

/lgtm