Configure Custom Git Repositories
TOC
Feature OverviewPrerequisitesRepository LayoutRepository ConfigMapCross-namespace Global Repository ConfigMapNamespace-scoped Repository ConfigMapProject-scoped Repository ConfigMapExact Namespace allowlistOptional kind paths and legacy catalog aliasesConfigMap Resource SyncSupported CredentialsExamplesPublic HTTPS RepositoryHTTPS Repository with TokenHTTPS Repository with Username and PasswordSSH Repository with known_hostsHTTPS Repository with Internal CAUse with the Hub ResolverVerificationLearn MoreFeature Overview
artifacthub-shim can load additional Tekton catalog resources from Git
repositories. Repositories are declared in labeled ConfigMaps. If a Git
repository is private or uses an internal CA, its repository entry can reference
a Secret in the same watched namespace.
The same Git repository entry can also declare extraResources directories.
Those directories are synchronized to the cluster as ConfigMaps when
config.extraResourceSync.enabled=true.
Each nested repository name becomes the external catalog name used by
Artifact Hub API paths, UI paths, and Tekton hub resolver catalog parameters.
Treat it as a stable identifier.
Prerequisites
artifacthub-shimis installed and ready.config.enableConfigMapSourcesistrue.- You can create ConfigMaps and Secrets in the namespace watched by
artifacthub-shim. By default, this is the install namespace. - To register globally visible repositories from another namespace,
config.globalConfigMapSources.enabledmust betrue. This is enabled by default.config.globalConfigMapSources.allowedNamespacescan restrict which namespaces may promote repositories to global visibility. - To register namespace, project, or explicit-allowlist repositories,
config.scopedConfigMapSources.enabledmust betrue. This is enabled by default. - The Git repository follows the expected catalog layout.
- Runtime ConfigMap resource sync is enabled when you want to import
extraResourcesdirectories. By default, only thekube-publicnamespace is allowed.
Repository Layout
The path field points to one resource-kind directory inside the Git
repository. Under that path, each package has version directories.
For each version directory, artifacthub-shim first looks for
<package>.yaml or <package>.yml. If neither exists, it falls back to the
single Tekton YAML file whose Kubernetes kind matches the configured source
kind.
Repository ConfigMap
Each repository ConfigMap must have the
artifacthub-shim.alauda.io/repository: "true" label and a repository.yaml
data key. The repository.yaml payload must contain a gitRepositories list.
Each gitRepositories[] item declares one Git source. Each nested
repositories[] item declares one externally visible catalog repository loaded
from that Git source. If any item in a ConfigMap is invalid, artifacthub-shim
rejects the whole ConfigMap.
ConfigMaps in the primary watched namespace, configured by config.namespace,
keep the existing behavior and default to global visibility. ConfigMaps in any
other namespace default to visibility from only that namespace. Set
artifacthub-shim.alauda.io/repository-visibility to global, project, or
namespace to choose an explicit scope. Project membership is derived only
from the owner Namespace label cpaas.io/project.
The annotation
artifacthub-shim.alauda.io/repository-visible-namespaces takes precedence over
the visibility label. Its comma-separated value is an exact Namespace allowlist;
entries are trimmed and deduplicated and may span projects. An empty value, an
invalid Namespace name, or a list with no existing Namespace invalidates the
whole ConfigMap scope and removes its previous content from the serving index.
When only some Namespace entries do not exist, those entries are ignored and the
remaining existing Namespaces continue to receive the repository.
Cross-namespace Global Repository ConfigMap
Use this pattern when a plugin or administrator owns the repository ConfigMap in a namespace different from the artifacthub-shim watched namespace, but the catalog should still be globally visible. Global repository ConfigMap discovery is enabled by default and covers all namespaces. The chart grants artifacthub-shim cluster-scoped read access to ConfigMaps, referenced Secrets, and Events while this feature is enabled.
If credentialRef.name is set, the Secret is resolved in the same namespace as
the repository ConfigMap. Secret changes in cross-namespace source namespaces
are picked up on the next repository refresh; updating the repository ConfigMap
also triggers an immediate refresh.
Namespace-scoped Repository ConfigMap
This is the default for repository ConfigMaps outside the primary watched
namespace. Only workloads and namespace-aware UI requests from team-a can use
the catalog.
Project-scoped Repository ConfigMap
All Namespaces whose cpaas.io/project label equals the owner Namespace label
can use the catalog. If the owner has no project label, the scope is invalid.
Exact Namespace allowlist
The annotation overrides any global, project, or namespace label:
Scoped ConfigMaps must not declare extraResources. A credentialRef always
resolves a Secret in the repository ConfigMap Namespace and cannot reference a
Secret in another Namespace.
Namespace-aware UI APIs filter Task, Pipeline, and StepAction records before
search, pagination, batch lookup, and content reads. Hub ResolutionRequest
creation is also checked by the extension validating webhook. A denied request
reports CATALOG_VISIBILITY_DENIED; unknown catalogs and internal policy errors
are allowed through so the Hub resolver can return its native result.
Supported kind values:
Supported top-level repository.yaml fields:
Supported gitRepositories[] fields:
Supported gitRepositories[].repositories[] fields:
Optional kind paths and legacy catalog aliases
Use optional: true only when a repository entry intentionally represents a
kind directory that may not exist yet. This is mainly useful for migrated
Tekton Hub catalogs where the old catalog had only task/, only pipeline/,
or mixed kind coverage. Strict validation remains the default for hand-written
repository entries.
legacyCatalogAliases preserves old resolver references during migration. The
alias is scoped by kind: a Pipeline alias does not resolve Tasks with the same
catalog name. A self alias is ignored. If an alias points to multiple
repositories or conflicts with another canonical repository name for that kind,
the shim disables only that alias and keeps every canonical repository ready.
Example migrated catalog:
With this configuration, old Pipeline references that still use
catalog: team-a resolve to the canonical team-a-pipelines repository.
New references should use catalog: team-a-pipelines directly.
Supported gitRepositories[].extraResources[] fields:
ConfigMap Resource Sync
extraResources currently imports only apiVersion: v1, kind: ConfigMap
documents that opt in with
metadata.labels["artifacthub-shim.alauda.io/import"] set to "true".
Add this label to the ConfigMap YAML stored in the Git repository. Unlabeled
ConfigMaps, non-ConfigMap resources, and unrelated files are skipped. Each
imported ConfigMap must set metadata.name and metadata.namespace. The
namespace must be listed in
config.extraResourceSync.allowedNamespaces; the chart default is kube-public.
Resource paths must stay inside the Git repository checkout. Symbolic links are not followed during resource scans.
The resource sync controller automatically stamps synchronized in-cluster
ConfigMaps with artifacthub-shim ownership labels such as
artifacthub-shim.alauda.io/controller-namespace,
artifacthub-shim.alauda.io/controller-name, and
artifacthub-shim.alauda.io/resource-set. If a same-name ConfigMap already
exists but does not have matching ownership labels, artifacthub-shim skips it
and never adopts or overwrites it.
When two resource sources declare the same desired ConfigMap, the conflict is handled per ConfigMap object. Other ConfigMaps from the same sources continue to sync. If the built-in catalog declares one of the duplicates, the built-in catalog version wins; otherwise the duplicate ConfigMap is skipped until the source manifests are made unique.
When a synchronized ConfigMap disappears from the source directory, artifacthub-shim deletes it from the cluster. To keep a synchronized ConfigMap after it is removed from Git, add this annotation to the in-cluster ConfigMap:
Supported Credentials
The referenced Secret can contain one or more of these keys:
Each Git repository can reference a different Secret.
Examples
Public HTTPS Repository
Use this pattern when the Git repository does not require authentication.
HTTPS Repository with Token
Use token for Git providers that accept personal access tokens or deploy
tokens over HTTPS. When username is omitted, artifacthub-shim uses
oauth2 as the username for the Git credential prompt.
HTTPS Repository with Username and Password
Use this pattern when your Git server requires a username and password pair.
SSH Repository with known_hosts
Use sshPrivateKey or ssh-privatekey for SSH authentication. The Secret must
also provide known_hosts; host key verification is strict by default.
HTTPS Repository with Internal CA
Use ca.crt when the Git server presents a certificate signed by an internal
CA. You can combine ca.crt with token, username, or password in the
same Secret.
Use with the Hub Resolver
The nested repositories[].name is the catalog value used by the hub resolver.
For example, the team-a-tasks repository declared above is consumed with
catalog: team-a-tasks:
Verification
After applying the ConfigMap and optional Secret, inspect the Events on the repository ConfigMap:
Expected Events:
RepositoryConfigAcceptedmeansrepository.yamlwas accepted.RepositorySourceReadymeans the repository source was indexed and is now visible to the DevOps Hub UI and hub resolver clients.
You can also list recent repository ConfigMap Events directly:
If the repository does not become visible, check for
RepositoryConfigInvalid, RepositorySourceInvalid, or
RepositorySourceDegraded Events first. Use the artifacthub-shim pod logs as
the secondary source for full Git or manifest parsing details.
For persistent Warning states, artifacthub-shim records the Warning again on
each refresh or resource sync attempt. Kubernetes usually keeps this as one
Event with an increasing count and updated last timestamp. If event TTL cleanup
removes the previous Event, the next attempt can create it again.
Kubernetes Events are still historical and may keep older Warning entries until
event TTL cleanup. Prefer the latest repository Event and /api/v1/snapshot
source statuses when deciding whether the current configuration is healthy.