Adding Custom Catalogs to Tekton Hub
TOC
OverviewPrerequisitesAdding Custom CatalogsStep 1: Prepare Your Catalog RepositoryStep 2: Configure the API ConfigMapStep 3: Apply the ConfigurationStep 4: Apply ChangesPrerequisites for Custom CatalogsManaging Multiple CatalogsPrivate Repository AuthenticationSSH Key AuthenticationPrerequisitesCreating SSH SecretGenerating known_hosts EntriesUsing SSH URLs in Catalog ConfigurationVerification and TestingVerify Catalog ConfigurationTest Resource ResolutionTroubleshootingCatalog Not AppearingResources Not LoadingSSH Authentication FailuresResource Resolution FailuresFAQQ: I configured according to the documentation, but still can't see the new catalogOverview
This guide explains how to configure a Tekton Hub instance to include custom catalogs from existing Git repositories. If you need to create a new catalog repository first, see Creating a Custom Catalog.
Custom catalogs allow organizations to share their Tekton resources through Tekton Hub, making them discoverable via the Hub resolver and web interface.
Important: If you deployed
Tekton HubthroughTektonConfig, modify the catalog configuration in theTektonConfigresource instead of directly editing theConfigMap. DirectConfigMapmodifications will be overridden by theTekton Operatorcontroller.
Namespace Note: Throughout this guide,
<tekton-pipelines>is used as a placeholder for yourTekton Hubnamespace. Replace it with your actual namespace name. The default installation usestekton-pipelinesnamespace.
Prerequisites
Before you begin, ensure you have:
- A Kubernetes cluster with Tekton Pipelines installed
- A running Tekton Hub instance
- Administrator access to the cluster
- A Git repository containing your custom Tekton resources following the Tekton Catalog structure
Adding Custom Catalogs
Step 1: Prepare Your Catalog Repository
Ensure your catalog repository follows the Tekton Catalog Organization TEP structure (see the tutorials section for details).
Step 2: Configure the API ConfigMap
Add your custom catalog to the tekton-hub-api ConfigMap in the CATALOGS section:
Catalog Configuration Fields:
Field Usage Details:
org: Used for organizing and grouping catalogs in the Hub UI. Can be any meaningful string representing the catalog owner.type: Determines how the catalog is classified and displayed in the Hub interface:official: Official Tekton catalogs (typically maintained by Tekton team)community: Community-maintained catalogs (most common choice)enterprise: Enterprise/company-specific catalogsprivate: Private catalogs (internal use)
provider: Specifies the Git platform for proper API integration and authentication:github: GitHub and GitHub Enterprisegitlab: GitLab and GitLab self-hosted
URL Configuration Priority:
-
sshurlhas higher priority thanurl- when both are provided,sshurlwill be used for git operations -
For Public Repositories: Use only
urlwith HTTPS format -
For Private Repositories: Must provide both
urlandsshurl-urlis required for database storage,sshurlis used for actual git operations
Important: url is always required due to database constraints, even when using sshurl for private repositories.
Step 3: Apply the Configuration
Apply the updated ConfigMap to your cluster:
Step 4: Apply Changes
After updating the ConfigMap, apply the changes:
Option 1: Restart the API Pod
Option 2: Wait for Automatic Refresh
The catalog will be automatically refreshed based on the configured CATALOG_REFRESH_INTERVAL.
Prerequisites for Custom Catalogs
Before adding a custom catalog to Tekton Hub, your repository must meet these requirements:
- Repository Structure: Follow the Tekton Catalog Organization standard
- Resource Validation: All Tasks/Pipelines must include required metadata
- Documentation: Each resource must have proper README and examples
For detailed instructions on creating compliant catalog repositories, see Creating a Custom Catalog.
Managing Multiple Catalogs
You can configure multiple catalogs in the same Tekton Hub instance:
Best Practices:
- Use descriptive, unique catalog names
- Keep catalog names consistent across environments
- Use appropriate Git revisions (main/master for stable, develop for testing)
Private Repository Authentication
SSH Key Authentication
For accessing private Git repositories or repositories from private Git instances, you need to create SSH credentials as a Kubernetes secret.
Prerequisites
- SSH keys should exist in your
~/.sshdirectory - The SSH public key should be added to your Git repository's deploy keys or your user account
Creating SSH Secret
Create a Kubernetes secret named tekton-hub-api-ssh-crds with your SSH credentials:
Important Notes:
- The secret must be named exactly
tekton-hub-api-ssh-crds - The secret must be created in the same namespace as your Tekton Hub installation
- Include all three files: private key, public key, and known_hosts
Generating known_hosts Entries
Important: You must generate the known_hosts file by actually connecting to the Git server to capture its SSH fingerprint. Simply copying example entries may not work due to server key changes or different Git providers.
Recommended Approach:
-
Test SSH connection locally to capture the server's fingerprint:
-
Alternative: Use ssh-keyscan to generate known_hosts entries:
-
Verify by cloning your repositories locally using both URLs:
Example known_hosts Entry (generated after successful SSH connection):
Using SSH URLs in Catalog Configuration
When configuring catalogs that require SSH authentication, provide both url and sshurl fields:
Note: Both url (HTTPS) and sshurl (SSH) are required for private repositories. The sshurl will be used for actual git operations.
Verification and Testing
Verify Catalog Configuration
After adding a custom catalog, verify it's properly configured:
Tips: The default Tekton Hub API endpoint is
tekton-hub-api.tekton-pipelines:8000, which is only accessible within the cluster.For the
<your-tekton-hub-api>placeholder in the commands below:
- Inside the
tekton-hub-apipod: uselocalhost:8000- From other pods in the cluster: use
tekton-hub-api.tekton-pipelines:8000- From outside the cluster: create a
NodePortservice orIngress(not covered in this guide)For testing purposes, you can run these commands inside the
tekton-hub-apipod usingwget.
Test Resource Resolution
Test that resources can be resolved via Hub resolver:
Troubleshooting
Catalog Not Appearing
Issue: Catalog configured but not showing in API
Solutions:
- Check ConfigMap was applied:
kubectl get cm tekton-hub-api -o yaml - Restart API pod:
kubectl delete pod app=tekton-hub-api -n <tekton-pipelines> - Check API logs:
kubectl logs deployment/tekton-hub-api -n <tekton-pipelines>
Resources Not Loading
Issue: Catalog appears but resources are missing
Possible Causes:
- Repository structure doesn't follow standard
- Required metadata missing (see Creating a Custom Catalog)
- Git repository authentication issues
Solutions:
- Check API logs for parsing errors
- Validate resource YAML syntax with
kubectl apply --dry-run
SSH Authentication Failures
Issue: Private repository access denied
Solutions:
- Verify secret exists:
kubectl get secret tekton-hub-api-ssh-crds - Verify known_hosts includes your Git server
- Test SSH connection manually from a pod
Resource Resolution Failures
Issue: Hub resolver cannot find resources
Common Causes:
- Catalog name mismatch between ConfigMap and resolver parameters
- Resource name/version doesn't match directory structure
- Resource failed validation during catalog parsing
Debug Steps:
FAQ
Q: I configured according to the documentation, but still can't see the new catalog
A: First, check the tekton-hub-api logs for authentication-related errors such as "Host key verification failed":
Common causes:
- SSH key lacks sufficient permissions for the repository
known_hostsfile missing the Git server's fingerprint- SSH key not properly added to repository deploy keys
Solution:
-
Test locally first: Ensure you can successfully clone the repository locally using the same SSH credentials:
-
Only after local clone succeeds, update your Kubernetes environment:
- Refer to the Generating known_hosts Entries section to properly generate the
known_hostsfile - Recreate the
tekton-hub-api-ssh-crdssecret with the working credentials - Restart the
tekton-hub-apipod and check the logs:
- Refer to the Generating known_hosts Entries section to properly generate the