Chart Configuration
This document describes the common Helm values for artifacthub-shim. The chart
defaults are optimized for a lightweight, offline-friendly installation with the
built-in Tekton catalog and no persistent runtime storage.
Use charts/artifacthub-shim/values.yaml as the source of truth for the full
value schema. The sections below focus on the values operators most commonly
override.
TOC
Basic settingsBuilt-in catalogExtension webhookRuntime refresh and repository discoveryLoggingUI API RBACRuntime storageCache and payload limitsNetwork exposureResources and schedulingExtension pointsExample: minimal offline installationExample: external accessExample: persistent source workdirExample: larger catalog with ContentStoreBasic settings
Built-in catalog
When catalog.enabled=true and config.sources is empty, the process creates
default sources for task and pipeline under the catalog root. The optional
catalog-stepactions source is created only when the packaged catalog contains a
stepaction/ directory.
Set catalog.enabled=false when you provide only custom static sources or only
ConfigMap-backed Git repository sources.
Extension webhook
artifacthub-shim-extension is a separate Deployment from the API server. It
does not serve Artifact Hub APIs; it hosts admission webhook capabilities used
by catalog integrations. The first enabled capability is template rendering for
TaskRuns that carry the configured template-render parameters.
The ResolutionRequest policy does not read hubresolver-config or discover the
resolver Deployment. It skips requests that explicitly use Tekton Hub and
reviews explicit Artifact Hub requests, plus requests that omit type, against
the local shim index. Requests without explicit catalog, kind, name, or
version parameters fail open because the webhook cannot safely reconstruct
resolver defaults.
When extension.webhook.certManager.enabled=true, the target cluster must have
cert-manager installed. If certificate management is provided externally, set
extension.webhook.certManager.enabled=false and provide the configured webhook
certificate Secret name through extension.webhook.certManager.secretName.
The API and extension Deployments both use the root nodeSelector,
tolerations, affinity, and priorityClassName scheduling values.
Runtime refresh and repository discovery
Logging
The chart writes JSON logs at info level by default. See
Logging for advanced zap file configuration.
UI API RBAC
The chart grants the API ServiceAccount permission to read
kube-public/global-info and to create TokenReview and
SubjectAccessReview objects. The process protects UI-compatible endpoints with
the shared requestauth flow:
GETandPOSTcollection endpoints under/api/v1alpha1/{tasks,pipelines,stepactions}requirelist hub.tekton.dev/resources. Whennamespaceis supplied, the SubjectAccessReview targets that Namespace and scope filtering happens before pagination or batch aggregation.- Detail endpoints under
/api/v1alpha1/{catalog}/{kind}/{name}[/version]and raw manifest URLs under/v1/resource/{catalog}/{kind}/{name}/{version}/yamlrequireget hub.tekton.dev/resources. A hidden catalog returns404and generated links preserve thenamespacequery. - Platform authentication is attempted first when enabled and when
platformURLandclusterNameare configured directly or discovered fromkube-public/global-info. It sends the request bearer token to{platformURL}/kubernetes/{clusterName}and uses platformSelfSubjectReviewplusSelfSubjectAccessReview. - Explicit OIDC verification is attempted next only when
config.authentication.oidc.enabled=true. OIDC-authenticated users are authorized with current-clusterSubjectAccessReview. - Current-cluster Kubernetes
TokenReviewfallback is attempted last whenconfig.authentication.kubernetesFallback=true, and the returned user is authorized with current-clusterSubjectAccessReview. - The process does not accept tokens by only decoding an unsigned Dex/JWT payload; tokens must be accepted by one of the configured shared backends.
- Resolver-compatible Artifact Hub endpoints under
/api/v1/packages/...remain unauthenticated so Tekton hub resolver can continue to call them without an end-user token.
No Erebus or KUBERNETES_SERVICE_HOST environment injection is required for
platform authentication. If the Hub UI Ingress must use the global-cluster
IngressClass, set config.globalCluster.enabled=true or set
hubIngress.className explicitly.
Runtime storage
sourceWorkDir is storage for materialized repository sources and provider
caches. For current ConfigMap-backed Git sources, this is where checkouts are
kept between refreshes. Persisting it can reduce pod-recreation cost by avoiding
a full reclone. During the first refresh after startup, a PVC-backed workdir can
serve a valid persisted checkout without waiting for a network fetch; later
refreshes still fetch, check out the requested revision, scan source files, and
rebuild the in-memory metadata index.
PVC-backed sourceWorkDir storage is supported only for single-replica
deployments. With multiple replicas, use emptyDir so every pod owns an
independent checkout directory.
ContentStore is optional storage for immutable Tekton manifest and README
payloads. It stores payload bytes by digest. It is not the metadata index: the
package index, version lookup maps, search tokens, and source status are still
built in memory for each pod.
The default is storage.contentStore.enabled=false, which keeps manifest and
README payloads in the in-memory snapshot. This is the simplest mode and is
appropriate for the built-in catalog and small custom catalog sets.
For multi-replica deployments, keep ContentStore disabled unless there is a
measured memory issue. If you must enable it with multiple replicas, prefer
emptyDir so each pod has independent local payload storage. PVC-backed
runtime storage is single-replica only.
When either sourceWorkDir or enabled ContentStore uses PVC-backed storage, the
chart renders the Deployment with strategy.type: Recreate to avoid old and new
pods writing the same runtime storage during an upgrade.
Cache and payload limits
Network exposure
Resources and scheduling
Extension points
Example: minimal offline installation
This keeps the built-in catalog enabled and keeps manifest/README payloads in the in-memory snapshot.
Example: external access
Use one of these patterns when a test client or external integration must reach the service directly.
Example: persistent source workdir
Use this for single-replica deployments with large external repository sources when full reclones are a noticeable part of pod restart time. This persists materialized source checkouts, not the metadata index. After a pod recreation, the first refresh can publish from the persisted checkout before performing a network fetch.
Example: larger catalog with ContentStore
Use this only when repository count or payload size creates measurable memory pressure. The index metadata still stays in memory, but manifest and README payload bytes are stored on the pod filesystem and read through the payload cache.