Custom Tekton Hub instance


Red Hat OpenShift Pipelines 1.21

Installing a custom instance of Tekton Hub

Red Hat OpenShift Documentation Team

Abstract

This document provides information about installing and deploying a custom instance of Tekton Hub.

Important

Tekton Hub is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Tekton Hub helps you discover, search, and share reusable tasks and pipelines for your CI/CD workflows. A public instance of Tekton Hub is available at hub.tekton.dev. Cluster administrators can also install and deploy a custom instance of Tekton Hub by modifying the configurations in the TektonHub custom resource (CR).

Tekton Hub is an optional component; cluster administrators cannot install it by using the TektonConfig custom resource (CR). To install and manage Tekton Hub, use the TektonHub CR.

You can install Tekton Hub on your cluster by using two modes:

  • Without login authorization and ratings for Tekton Hub artifacts
  • with login authorization and ratings for Tekton Hub artifacts
Note

If you are using GitHub Enterprise or GitLab Enterprise, install and deploy Tekton Hub in the same network as the enterprise server. For example, if the enterprise server is running behind a VPN, deploy Tekton Hub on a cluster that is also behind the VPN.

You can install Tekton Hub on your cluster automatically with default configuration. When using the default configuration, Tekton Hub does not support login with authorization and ratings for Tekton Hub artifacts.

Prerequisites

  • You installed the Red Hat OpenShift Pipelines Operator in the default openshift-pipelines namespace on the cluster.

Procedure

  1. Create a TektonHub CR similar to the following example.

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonHub
    metadata:
      name: hub
    spec:
      targetNamespace: openshift-pipelines
      db:                      # Optional: If you want to use custom database
        secret: tekton-hub-db  # Name of db secret should be `tekton-hub-db`
    
      categories:              # Optional: If you want to use custom categories
        - Automation
        - Build Tools
        - CLI
        - Cloud
        - Code Quality
        - ...
    
      catalogs:                # Optional: If you want to use custom catalogs
        - name: tekton
          org: tektoncd
          type: community
          provider: github
          url: https://github.com/tektoncd/catalog
          revision: main
    
      scopes:                   # Optional: If you want to add new users
        - name: agent:create
          users: [abc, qwe, pqr]
        - name: catalog:refresh
          users: [abc, qwe, pqr]
        - name: config:refresh
          users: [abc, qwe, pqr]
    
      default:                   # Optional: If you want to add custom default scopes
        scopes:
          - rating:read
          - rating:write
    
      api:
        catalogRefreshInterval: 30m
    spec.targetNamespace
    The namespace in which you install Tekton Hub; default is openshift-pipelines.
    spec.api.catalogRefreshInterval

    The time interval after which the catalog refreshes automatically. The supported units of time are seconds (s), minutes (m), hours (h), days (d), and weeks (w). The default interval is 30 minutes.

    Note

    If you don’t give custom values for the optional fields in the TektonHub CR, the system uses the default values configured in the Tekton Hub API config map.

  2. Apply the TektonHub CR.

    $ oc apply -f <tekton_hub_cr>.yaml
  3. Check the status of the installation. The TektonHub CR might take some time to reach steady state.

    $ oc get tektonhub.operator.tekton.dev

    Sample output

    NAME   VERSION   READY   REASON   APIURL                    UIURL
    hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

1.1.2. Installing Tekton Hub with login and rating

You can install Tekton Hub on your cluster with custom configuration that supports login with authorization and ratings for Tekton Hub artifacts.

Prerequisites

  • You installed the Red Hat OpenShift Pipelines Operator in the default openshift-pipelines namespace on the cluster.

Procedure

  1. Create an OAuth application with your Git repository hosting provider, and note the Client ID and Client Secret. The supported providers are GitHub, GitLab, and Bitbucket.

  2. Edit the <tekton_hub_root>/config/02-api/20-api-secret.yaml file to include the Tekton Hub API secrets. For example:

    apiVersion: v1
    kind: Secret
    metadata:
      name: tekton-hub-api
      namespace: openshift-pipelines
    type: Opaque
    stringData:
      GH_CLIENT_ID:
      GH_CLIENT_SECRET:
      GL_CLIENT_ID:
      GL_CLIENT_SECRET:
      BB_CLIENT_ID:
      BB_CLIENT_SECRET:
      JWT_SIGNING_KEY:
      ACCESS_JWT_EXPIRES_IN:
      REFRESH_JWT_EXPIRES_IN:
      AUTH_BASE_URL:
      GHE_URL:
      GLE_URL:
    GH_CLIENT_ID
    The Client ID from the GitHub OAuth application.
    GH_CLIENT_SECRET
    The Client Secret from the GitHub OAuth application.
    GL_CLIENT_ID
    The Client ID from the GitLab OAuth application.
    GL_CLIENT_SECRET
    The Client Secret from the GitLab OAuth application.
    BB_CLIENT_ID
    The Client ID from the Bitbucket OAuth application.
    BB_CLIENT_SECRET
    The Client Secret from the Bitbucket OAuth application.
    JWT_SIGNING_KEY
    A long, random string used to sign the JSON Web Token (JWT) created for users.
    ACCESS_JWT_EXPIRES_IN
    Add the time limit after which the access token expires. For example, 1m, where m denotes minutes. The supported units of time are seconds (s), minutes (m), hours (h), days (d), and weeks (w).
    REFRESH_JWT_EXPIRES_IN
    Add the time limit after which the refresh token expires. For example, 1m, where m denotes minutes. The supported units of time are seconds (s), minutes (m), hours (h), days (d), and weeks (w). Ensure that the expiry time set for token refresh is greater than the expiry time set for token access.
    AUTH_BASE_URL
    Route URL for the OAuth application.
    GHE_URL
    GitHub Enterprise URL, if you are authenticating using GitHub Enterprise. Do not give the URL to the catalog as a value for this field.
    GLE_URL

    GitLab Enterprise URL, if you are authenticating using GitLab Enterprise. Do not give the URL to the catalog as a value for this field.

    Note

    You can delete the unused fields for the Git repository hosting service providers that are irrelevant to your deployment.

  3. Create a TektonHub CR similar to the following example.

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonHub
    metadata:
      name: hub
    spec:
      targetNamespace: openshift-pipelines
      db:
        secret: tekton-hub-db
    
      categories:
        - Automation
        - Build Tools
        - CLI
        - Cloud
        - Code Quality
          ...
    
      catalogs:
        - name: tekton
          org: tektoncd
          type: community
          provider: github
          url: https://github.com/tektoncd/catalog
          revision: main
    
      scopes:
        - name: agent:create
          users: [<username>]
        - name: catalog:refresh
          users: [<username>]
        - name: config:refresh
          users: [<username>]
    
      default:
        scopes:
          - rating:read
          - rating:write
    
      api:
        catalogRefreshInterval: 30m
    targetNamespace
    The namespace in which you install Tekton Hub; default is openshift-pipelines.
    db
    Optional: Custom database, such as a Crunchy Postgres database.
    secret
    The name of the database secret must be tekton-hub-db.
    categories
    Optional: Customized categories for tasks and pipelines in Tekton Hub.
    catalogs
    Optional: Customized catalogs for Tekton Hub.
    scopes
    Optional: Additional users. You can mention many users, such as [<username_1>, <username_2>, <username_3>].
    default
    Optional: Customized default scopes.
    catalogRefreshInterval

    The time interval after which the catalog refreshes automatically. The supported units of time are seconds (s), minutes (m), hours (h), days (d), and weeks (w). The default interval is 30 minutes.

    Note

    If you don’t give custom values for the optional fields in the TektonHub CR, the system uses the default values configured in the Tekton Hub API config map.

  4. Apply the TektonHub CR.

    $ oc apply -f <tekton_hub_cr>.yaml
  5. Check the status of the installation. The TektonHub CR might take some time to reach steady state.

    $ oc get tektonhub.operator.tekton.dev

    Sample output

    NAME   VERSION   READY   REASON   APIURL                    UIURL
    hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

Cluster administrators can use a custom database with Tekton Hub, instead of the default PostgreSQL database installed by the Operator. You can associate a custom database at the time of installation, and use it with the db-migration, api, and ui interfaces provided by Tekton Hub. Or, you can associate a custom database with Tekton Hub even after the installation with the default database is complete.

Procedure

  1. Create a secret named tekton-hub-db in the target namespace with the following keys:

    • POSTGRES_HOST
    • POSTGRES_DB
    • POSTGRES_USER
    • POSTGRES_PASSWORD
    • POSTGRES_PORT

      Example: Custom database secrets

      apiVersion: v1
      kind: Secret
      metadata:
        name: tekton-hub-db
        labels:
          app: tekton-hub-db
      type: Opaque
      stringData:
        POSTGRES_HOST: <The name of the host of the database>
        POSTGRES_DB: <Name of the database>
        POSTGRES_USER: <username>
        POSTGRES_PASSWORD: <password>
        POSTGRES_PORT: <The port that the database is listening on>
      ...

      Note

      The default target namespace is openshift-pipelines.

  2. In the TektonHub CR, set the value of the database secret attribute to tekton-hub-db.

    Example: Adding custom database secret

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonHub
    metadata:
      name: hub
    spec:
      targetNamespace: openshift-pipelines
      db:
        secret: tekton-hub-db
      api:
        hubConfigUrl: https://raw.githubusercontent.com/tektoncd/hub/main/config.yaml
        catalogRefreshInterval: 30m
    ...

  3. Use the updated TektonHub CR to associate the custom database with Tekton Hub.

    1. If you are associating the custom database at the time of installing Tekton Hub on your cluster, apply the updated TektonHub CR.

      $ oc apply -f <tekton_hub_cr>.yaml
    2. Or, if you are associating the custom database after the installation of Tekton Hub is complete, replace the existing TektonHub CR with the updated TektonHub CR.

      $ oc replace -f <tekton_hub_cr>.yaml
  4. Check the status of the installation. The TektonHub CR might take some time to reach steady state.

    $ oc get tektonhub.operator.tekton.dev

    Sample output

    NAME   VERSION   READY   REASON   APIURL                    UIURL
    hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

Cluster administrators can install the Crunchy Postgres database and configure Tekton Hub to use it instead of the default database.

Prerequisites

  • Install the Crunchy Postgres Operator from the OperatorHub.
  • Create a Postgres instance that initiates a Crunchy Postgres database.

Procedure

  1. Get into the Crunchy Postgres pod.

    Example: Getting into the test-instance1-m7hh-0 pod

    $ oc exec -it -n openshift-operators test-instance1-m7hh-0 -- /bin/sh
    
    Defaulting container name to database.
    Use 'oc describe pod/test-instance1-m7hh-0 -n openshift-operators' to see all of the containers in this pod.
    sh-4.4$ psql -U postgres
    psql (14.4)
    Type "help" for help.

  2. Find the pg_hba.conf file.

    postgres=# SHOW hba_file;
             hba_file
    --------------------------
     /pgdata/pg14/pg_hba.conf
    (1 row)
    
    postgres=#
  3. Exit from the database.
  4. Check if the pg_hba.conf file has the entry host all all 0.0.0.0/0 md5, required to access all incoming connections. In addition, add the entry at the end of the pg_hba.conf file.

    Example: pg_hba.conf file

    sh-4.4$ cat /pgdata/pg14/pg_hba.conf
    
    # Do not edit this file manually!
    # It will be overwritten by Patroni!
    local all "postgres" peer
    hostssl replication "_crunchyrepl" all cert
    hostssl "postgres" "_crunchyrepl" all cert
    host all "_crunchyrepl" all reject
    hostssl all all all md5
    host  all  all 0.0.0.0/0 md5

  5. Save the pg_hba.conf file and reload the database.

    sh-4.4$ psql -U postgres
    psql (14.4)
    Type "help" for help.
    
    postgres=# SHOW hba_file;
             hba_file
    --------------------------
     /pgdata/pg14/pg_hba.conf
    (1 row)
    
    postgres=# SELECT pg_reload_conf();
     pg_reload_conf
    ----------------
     t
    (1 row)
  6. Exit the database.
  7. Decode the secret value of the Crunchy Postgres host.

    Example: Decode the secret value of a Crunchy Postgres host

    $ echo 'aGlwcG8tcHJpbWFyeS5vcGVuc2hpZnQtb3BlcmF0b3JzLnN2YyA=' | base64 --decode
    test-primary.openshift-operators.svc

  8. Create a secret named tekton-hub-db in the target namespace with the following keys:

    • POSTGRES_HOST
    • POSTGRES_DB
    • POSTGRES_USER
    • POSTGRES_PASSWORD
    • POSTGRES_PORT

      Example: Custom database secrets

      apiVersion: v1
      kind: Secret
      metadata:
        name: tekton-hub-db
        labels:
          app: tekton-hub-db
      type: Opaque
      stringData:
        POSTGRES_HOST: test-primary.openshift-operators.svc
        POSTGRES_DB: test
        POSTGRES_USER: <username>
        POSTGRES_PASSWORD: <password>
        POSTGRES_PORT: '5432'
      ...

    Note

    The default target namespace is openshift-pipelines.

  9. In the TektonHub CR, set the value of the database secret attribute to tekton-hub-db.

    Example: Adding custom database secret

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonHub
    metadata:
      name: hub
    spec:
      targetNamespace: openshift-pipelines
      db:
        secret: tekton-hub-db
    ...

  10. Use the updated TektonHub CR to associate the custom database with Tekton Hub.

    $ oc apply -f <tekton_hub_cr>.yaml
  11. Check the status of the installation. The TektonHub CR might take some time to reach a steady state.

    $ oc get tektonhub.operator.tekton.dev

    Sample output

    NAME   VERSION   READY   REASON   APIURL                    UIURL
    hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

Tekton Hub supports the use of Crunchy Postgres as a custom database. For a pre-installed Tekton Hub with default database, cluster administrators can use Crunchy Postgres as a custom database after migrating the Tekton Hub data from the internal or default database to the external Crunchy Postgres database.

Procedure

  1. Dump the existing data from the internal or default database into a file in the pod.

    Example: Dump data

    $ pg_dump -Ft -h localhost -U postgres hub -f /tmp/hub.dump

  2. Copy the file containing the data dump to your local system.

    Command format

    $ oc cp -n <namespace> <podName>:<path_to_hub.dump> <path_to_local_system>

    Example

    $ oc cp -n openshift-pipelines tekton-hub-db-7d6d888c67-p7mdr:/tmp/hub.dump /home/test_user/Downloads/hub.dump

  3. Copy the file that has the data dump from the local system to the pod running the external Crunchy Postgres database.

    Command format

    $ oc cp -n <namespace> <path_to_local_system> <podName>:<path_to_hub.dump>

    Example

    $ oc cp -n openshift-operators /home/test_user/Downloads/hub.dump test-instance1-spnz-0:/tmp/hub.dump

  4. Restore the data in the Crunchy Postgres database.

    Command format

    $ pg_restore -d <database_name> -h localhost -U postgres <path_where_file_is_copied>

    Example

    $ pg_restore -d test -h localhost -U postgres /tmp/hub.dump

  5. Get into the Crunchy Postgres pod.

    Example: Get into the test-instance1-m7hh-0 pod

    $ oc exec -it -n openshift-operators test-instance1-m7hh-0 -- /bin/sh
    
    Defaulting container name to database.
    Use 'oc describe pod/test-instance1-m7hh-0 -n openshift-operators' to see all of the containers in this pod.
    sh-4.4$ psql -U postgres
    psql (14.4)
    Type "help" for help.

  6. Find the pg_hba.conf file.

    postgres=# SHOW hba_file;
             hba_file
    --------------------------
     /pgdata/pg14/pg_hba.conf
    (1 row)
    
    postgres=#
  7. Exit from the database.
  8. Check if the pg_hba.conf file has the entry host all all 0.0.0.0/0 md5, which is necessary for accessing all incoming connections. If necessary, add the entry at the end of the pg_hba.conf file.

    Example: pg_hba.conf file

    sh-4.4$ cat /pgdata/pg14/pg_hba.conf
    
    # Do not edit this file manually!
    # It will be overwritten by Patroni!
    local all "postgres" peer
    hostssl replication "_crunchyrepl" all cert
    hostssl "postgres" "_crunchyrepl" all cert
    host all "_crunchyrepl" all reject
    hostssl all all all md5
    host  all  all 0.0.0.0/0 md5

  9. Save the pg_hba.conf file and reload the database.

    sh-4.4$ psql -U postgres
    psql (14.4)
    Type "help" for help.
    
    postgres=# SHOW hba_file;
             hba_file
    --------------------------
     /pgdata/pg14/pg_hba.conf
    (1 row)
    
    postgres=# SELECT pg_reload_conf();
     pg_reload_conf
    ----------------
     t
    (1 row)
  10. Exit the database.
  11. Verify that a secret named tekton-hub-db in the target namespace has the following keys:

    • POSTGRES_HOST
    • POSTGRES_DB
    • POSTGRES_USER
    • POSTGRES_PASSWORD
    • POSTGRES_PORT

      Example: Custom database secrets

      apiVersion: v1
      kind: Secret
      metadata:
        name: tekton-hub-db
        labels:
          app: tekton-hub-db
      type: Opaque
      stringData:
        POSTGRES_HOST: test-primary.openshift-operators.svc
        POSTGRES_DB: test
        POSTGRES_USER: test
        POSTGRES_PASSWORD: woXOisU5>ocJiTF7y{{;1[Q(
        POSTGRES_PORT: '5432'
      ...

      Note

      A secret encodes the value of the POSTGRES_HOST field. You can decode the value of the Crunchy Postgres host by using the following example.

      Example: Decode the secret value of a Crunchy Postgres host

      $ echo 'aGlwcG8tcHJpbWFyeS5vcGVuc2hpZnQtb3BlcmF0b3JzLnN2YyA=' | base64 --decode
      test-primary.openshift-operators.svc

  12. Verify that in the TektonHub CR, the value of the database secret attribute is tekton-hub-db.

    Example: TektonHub CR with the name of the database secret

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonHub
    metadata:
      name: hub
    spec:
      targetNamespace: openshift-pipelines
      db:
        secret: tekton-hub-db
    ...

  13. To associate the external Crunchy Postgres database with Tekton Hub, replace any existing TektonHub CR with the updated TektonHub CR.

    $ oc replace -f <updated_tekton_hub_cr>.yaml
  14. Check the status of the Tekton Hub. The updated TektonHub CR might take some time to reach a steady state.

    $ oc get tektonhub.operator.tekton.dev

    Sample output

    NAME   VERSION   READY   REASON   APIURL                    UIURL
    hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

Cluster administrators can update Tekton Hub with custom categories, catalogs, scopes, and default scopes that reflect the context of their organization.

Procedure

  1. Optional: Edit the categories, catalogs, scopes, and default:scopes fields in the Tekton Hub CR.

    Note

    The Tekton Hub API config map gives the default information for categories, catalog, scopes, and default scopes. If you give custom values in the TektonHub CR, it overrides the default values.

  2. Apply the Tekton Hub CR.

    $ oc apply -f <tekton_hub_cr>.yaml
  3. Observe the Tekton Hub status.

    $ oc get tektonhub.operator.tekton.dev

    Sample output

    NAME   VERSION   READY   REASON   APIURL                  UIURL
    hub    v1.9.0    True             https://api.route.url   https://ui.route.url

The default catalog refresh interval for Tekton Hub is 30 minutes. Cluster administrators can change the automatic catalog refresh interval by modifying the value of the catalogRefreshInterval field in the TektonHub CR.

Procedure

  1. Change the value of the catalogRefreshInterval field in the TektonHub CR.

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonHub
    metadata:
      name: hub
    spec:
      targetNamespace: openshift-pipelines
      api:
        catalogRefreshInterval: 30m
    targetNamespace
    The namespace where Tekton Hub is installed; default is openshift-pipelines.
    catalogRefreshInterval
    The time interval after which the catalog refreshes automatically. The supported units of time are seconds (s), minutes (m), hours (h), days (d), and weeks (w). The default interval is 30 minutes.
  2. Apply the TektonHub CR.

    $ oc apply -f <tekton_hub_cr>.yaml
  3. Check the status of the installation. The TektonHub CR might take some time to reach steady state.

    $ oc get tektonhub.operator.tekton.dev

    Sample output

    NAME   VERSION   READY   REASON   APIURL                    UIURL
    hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

1.5. Adding new users in Tekton Hub configuration

Cluster administrators can add new users to Tekton Hub with different scopes.

Procedure

  1. Change the TektonHub CR to add new users with different scopes.

    ...
    scopes:
      - name: agent:create
        users: [<username_1>, <username_2>]
      - name: catalog:refresh
        users: [<username_3>, <username_4>]
      - name: config:refresh
        users: [<username_5>, <username_6>]
    
    default:
      scopes:
        - rating:read
        - rating:write
    ...
    <username_2>

    The usernames registered with the Git repository hosting service provider.

    Note

    A new user signing in to Tekton Hub for the first time will have only the default scope. To activate additional scopes, ensure you add the user’s username in the scopes field of the TektonHub CR.

  2. Apply the updated TektonHub CR.

    $ oc apply -f <tekton_hub_cr>.yaml
  3. Check the status of the Tekton Hub. The updated TektonHub CR might take some time to reach a steady state.

    $ oc get tektonhub.operator.tekton.dev

    Sample output

    NAME   VERSION   READY   REASON   APIURL                    UIURL
    hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

  4. Refresh the configuration.

    $ curl -X POST -H "Authorization: <access_token>" \
        --header "Content-Type: application/json" \
        --data '{"force": true} \
        <api_route>/system/config/refresh
    <access_token>
    The JSON Web Token (JWT).

When you install Tekton Hub with Red Hat OpenShift Pipelines Operator 1.8, the default installation disables login authorization and ratings for the Tekton Hub artifacts. However, when you upgrade the Operator from 1.7 to 1.8, the instance of the Tekton Hub on your cluster does not automatically disable the login authorization and ratings.

To disable login authorization and ratings for Tekton Hub after upgrading the Operator from 1.7 to 1.8, perform the steps in the following procedure.

Prerequisites

  • You installed the Red Hat OpenShift Pipelines Operator in the default openshift-pipelines namespace on the cluster.

Procedure

  1. Delete the existing Tekton Hub API secret that you created while manually installing Tekton Hub for Operator 1.7.

    $ oc delete secret tekton-hub-api -n <targetNamespace>
    <targetNamespace>
    The common namespace for the Tekton Hub API secret and the Tekton Hub CR. By default, the target namespace is openshift-pipelines.
  2. Delete the TektonInstallerSet object for the Tekton Hub API.

    $ oc get tektoninstallerset -o name | grep tekton-hub-api | xargs oc delete
    Note

    After deletion, the Operator automatically creates a new Tekton Hub API installer set.

    Wait and check the status of the Tekton Hub. Proceed to the next steps when the READY column displays True.

    $ oc get tektonhub hub

    Sample output

    NAME   VERSION        READY   REASON   APIURL                                                                                                  UIURL
    hub    1.8.0          True             https://tekton-hub-api-openshift-pipelines.apps.example.com   https://tekton-hub-ui-openshift-pipelines.apps.example.com

  3. Delete the ConfigMap object for the Tekton Hub UI.

    $ oc delete configmap tekton-hub-ui -n <targetNamespace>
    <targetNamespace>
    The common namespace for the Tekton Hub UI and the Tekton Hub CR. By default, the target namespace is openshift-pipelines.
  4. Delete the TektonInstallerSet object for the Tekton Hub UI.

    $ oc get tektoninstallerset -o name | grep tekton-hub-ui | xargs oc delete
    Note

    After deletion, the Operator automatically creates a new Tekton Hub UI installer set.

    Wait and check the status of the Tekton Hub. Proceed to the next steps when the READY column displays True.

    $ oc get tektonhub hub

    Sample output

    NAME   VERSION        READY   REASON   APIURL                                                                                                  UIURL
    hub    1.8.0          True             https://tekton-hub-api-openshift-pipelines.apps.example.com   https://tekton-hub-ui-openshift-pipelines.apps.example.com

Legal Notice

Copyright © Red Hat.
Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . If you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.
The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top