Support multiple Artifact Hub URLs in the Hub Resolver

[vdemeester]

Feature request

Enable the Hub Resolver to be configured with multiple Artifact Hub (or Tekton Hub) URLs, allowing it to query multiple hub instances when resolving Tasks, Pipelines, or StepActions.

Use case

Organizations and teams want to independently manage and host their own Tekton resources (Tasks and Pipelines) on private Artifact Hub instances, rather than relying solely on the public artifacthub.io or a single centralized hub managed by a platform team.

Example scenarios:

1. Multi-team environments: Different teams maintain their own curated catalogs on separate Artifact Hub instances. A Pipeline should be able to reference resources from any of these hubs.
2. Air-gapped / private deployments: Organizations running in disconnected environments need to use internal Artifact Hub mirrors while optionally falling back to a cached public catalog.
3. Layered catalogs: Organizations want to maintain a hierarchy of catalogs (e.g., company-wide → team-specific → project-specific) where resources can be resolved from any layer.

Current behavior

The Hub Resolver currently supports only one Artifact Hub URL and one Tekton Hub URL, configured via environment variables on the resolver deployment:

# config/resolvers/resolvers-deployment.yaml
env:
  - name: ARTIFACT_HUB_API
    value: "https://artifacthub.io/"
  - name: TEKTON_HUB_API
    value: ""

These are read at startup in cmd/resolvers/main.go and passed to the resolver:

tektonHubURL := buildHubURL(os.Getenv("TEKTON_HUB_API"), "")
artifactHubURL := buildHubURL(os.Getenv("ARTIFACT_HUB_API"), hubresolution.DefaultArtifactHubURL)

The resolver struct only holds single URL strings:

type Resolver struct {
    TektonHubURL   string
    ArtifactHubURL string
}

To use resources from multiple hub instances today, users must either:

• Deploy multiple resolver instances with different configurations (complex, hard to manage)
• Copy all resources to a single hub (defeats the purpose of distributed ownership)

Proposed solution

Option A: Per-resolution URL parameter

Add a url parameter to the hub resolver (similar to the git resolver which already supports url as a per-resolution parameter):

taskRef:
  resolver: hub
  params:
    - name: url
      value: https://internal-hub.example.com/
    - name: catalog
      value: my-team-catalog
    - name: name
      value: my-task
    - name: version
      value: "1.0.0"

This would allow Pipeline authors to explicitly choose which hub to query. When url is not specified, it falls back to the cluster-configured default.

Option B: Multiple default URLs with fallback

Configure multiple hub URLs at the cluster level that the resolver queries in order:

# hubresolver-config ConfigMap
data:
  artifact-hub-urls: |
    - https://internal-hub.example.com/
    - https://artifacthub.io/

The resolver would query each hub in order and return the first successful match.

Option C: Both approaches combined

Implement both: cluster-level defaults for fallback behavior, plus per-resolution url override for explicit control.

Benefits

• Enables distributed catalog ownership across teams
• Supports air-gapped and private deployments
• Follows existing patterns (git resolver already has per-resolution url)
• Backwards compatible (current behavior unchanged when url not specified)

/kind feature
/area resolution