Hub Resolver

Use resolver type hub.

Parameters

The Catalogs in the Artifact Hub follows the semVer (i.e. <major-version>.<minor-version>.0) and the Catalogs in the Tekton Hub follows the simplified semVer (i.e. <major-version>.<minor-version>). Both full and simplified semantic versioning will be accepted by the version parameter. The Hub Resolver will map the version to the format expected by the target Hub type.

Requirements

• A cluster running Tekton Pipeline v0.41.0 or later.
• The built-in remote resolvers installed.
• The enable-hub-resolver feature flag in the resolvers-feature-flags ConfigMap in the tekton-pipelines-resolvers namespace set to true.
• Beta features enabled.

Configuration

This resolver uses a ConfigMap for its settings. See ../config/resolvers/hubresolver-config.yaml for the name, namespace and defaults that the resolver ships with.

Options

Configuring the Hub API endpoint

The Hub Resolver supports to resolve resources from the Artifact Hub and the Tekton Hub, which can be configured by setting the type field of the resolver.

** DEPRECATION NOTICE: Tekton Hub is deprecated. Users should migrate to Artifact Hub for discovering and managing Tekton resources. See the migration guide for more information.**

When setting the type field to artifact, the resolver will hit the public hub api at https://artifacthub.io/ by default but you can configure your own (for example to use a private hub instance) by setting the ARTIFACT_HUB_API environment variable in ../config/resolvers/resolvers-deployment.yaml. Example:

env
- name: ARTIFACT_HUB_API
  value: "https://artifacthub.io/"

When setting the type field to tekton, the resolver will hit the public tekton catalog api at https://api.hub.tekton.dev by default but you can configure your own instance of the Tekton Hub by setting the TEKTON_HUB_API environment variable in ../config/resolvers/resolvers-deployment.yaml. Example:

env
- name: TEKTON_HUB_API
  value: "https://api.private.hub.instance.dev"

The Tekton Hub deployment guide can be found here.

Usage

Task Resolution

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: remote-task-reference
spec:
  taskRef:
    resolver: hub
    params:
    - name: catalog # optional
      value: tekton-catalog-tasks
    - name: type # optional
      value: artifact 
    - name: kind
      value: task
    - name: name
      value: git-clone
    - name: version
      value: "0.6"

Pipeline Resolution

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: hub-demo
spec:
  pipelineRef:
    resolver: hub
    params:
    - name: catalog # optional
      value: tekton-catalog-pipelines 
    - name: type # optional
      value: artifact
    - name: kind
      value: pipeline
    - name: name
      value: buildpacks
    - name: version
      value: "0.1"
  # Note: the buildpacks pipeline requires parameters.
  # Resolution of the pipeline will succeed but the PipelineRun
  # overall will not succeed without those parameters.

Task Resolution from a Private Hub

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: private-hub-task-reference
spec:
  taskRef:
    resolver: hub
    params:
    - name: url
      value: https://internal-hub.example.com
    - name: catalog
      value: my-team-catalog
    - name: type
      value: artifact
    - name: kind
      value: task
    - name: name
      value: my-task
    - name: version
      value: "1.0.0"

When the url parameter is not specified, the resolver falls back to the cluster-configured defaults: first checking the ConfigMap URL lists (artifact-hub-urls / tekton-hub-urls), then the environment variables (ARTIFACT_HUB_API / TEKTON_HUB_API). This allows Pipeline authors to explicitly choose which hub instance to query on a per-resolution basis, which is useful in multi-team environments or air-gapped deployments where resources are hosted on private hub instances.

Configuring Multiple Hub URLs

You can configure multiple hub API URLs in the hubresolver-config ConfigMap. The resolver will try each URL in order and return the first successful result. This is useful for layered catalogs, multi-team environments, or air-gapped deployments where resources may exist on different hub instances.

apiVersion: v1
kind: ConfigMap
metadata:
  name: hubresolver-config
  namespace: tekton-pipelines-resolvers
data:
  artifact-hub-urls: |
    - https://internal-hub.example.com/
    - https://artifacthub.io/    
  tekton-hub-urls: |
    - https://internal-tekton-hub.example.com/
    - https://api.hub.tekton.dev/    

Note: All URLs (whether in the ConfigMap lists, the url parameter, or environment variables) must use http or https scheme. Other schemes (e.g., ftp://) will be rejected.

URL precedence (highest to lowest):

1. Per-resolution url parameter — single URL override for a specific resolution request
2. ConfigMap URL lists (artifact-hub-urls / tekton-hub-urls) — tried in order, first success wins
3. Environment variable (ARTIFACT_HUB_API / TEKTON_HUB_API) — single URL fallback
4. Default URL (https://artifacthub.io for artifact type)

If the ConfigMap URL list keys are not set (commented out by default), the resolver behaves exactly as before, using the environment variable or default URL.

Version constraint

Instead of a version you can specify a constraint to choose from. The constraint is a string as documented in the go-version library.

Some examples:

params:
  - name: name
    value: git-clone
  - name: version
    value: ">=0.7.0"

Will only choose the git-clone task that is greater than version 0.7.0

params:
  - name: name
    value: git-clone
  - name: version
    value: ">=0.7.0, < 2.0.0"

Will select the latest git-clone task that is greater than version 0.7.0 and less than version 2.0.0, so if the latest task is the version 0.9.0 it will be selected.

Other operators for selection are available for comparisons, see the go-version source code.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License.