Story (Required)

As a Pipelines-as-Code (PaC) user, when I run my `PipelineRuns` that reference tasks from Tekton Hub, I want them to continue working without manual changes by having PaC use ArtifactHub as the new source.

This story addresses the breaking change introduced by the announced shutdown of the public Tekton Hub (`hub.tekton.dev`). Many PaC users rely on the hub to resolve tasks by name (e.g., `git-clone`). The goal is to update PaC to use ArtifactHub as the backend for resolving these tasks, ensuring a seamless transition for users and preventing their workflows from breaking.

Background (Required)

The upstream Tekton community has announced the deprecation and shutdown of the public Tekton Hub instance (`hub.tekton.dev`). The API is scheduled to be shut down in September 2025, with the GitHub repository being archived in November 2025. The primary driver for this is the operational cost of the service.

This is a critical breaking change for Pipelines-as-Code, as PaC resolves task references like `

` by querying the Tekton Hub API. When the service is shut down, these resolutions will fail, breaking a significant number of user `PipelineRuns`.

While the long-term solution for users is to migrate to Tekton Resolvers, the announced timeline is too short for a manual migration across all customers. This story proposes updating PaC to use ArtifactHub as the new default catalog for resolving tasks by name.

An epic has been created to track the overall effort: SRVKP-8058.

Out of scope

• Forcing users to manually migrate their YAML files to use Tekton Resolvers.
• Implementing a full-featured ArtifactHub client in PaC for purposes other than resolving Tekton tasks.
• Changes to other components like Tekton CLI or the OpenShift Console. Those should be handled in separate tickets.
• Removing the Tekton Hub component from the downstream operator. This will be considered on a much longer timeline (e.g., 2026).

Approach (Required)

The technical approach is to replace the internal client for `hub.tekton.dev` with a new client for `artifacthub.io`.

1. *Implement ArtifactHub Client:* Create logic within PaC to query the ArtifactHub API to find Tekton tasks by name and version.
2. *Map Requests:* Since the Tekton Hub and ArtifactHub APIs are different, PaC will need to translate the user's request for a hub task into a valid ArtifactHub API query.
3. *Fetch Resource:* Fetch the task YAML from the location provided by the ArtifactHub API response. The resource content is expected to be identical to what was on Tekton Hub.
4. *User Experience:* This backend change should be completely transparent to the end-user. Their existing `PipelineRun` definitions that reference hub tasks should work without any modification.
5. *Logging:* Add clear logging to indicate that the task was resolved from ArtifactHub for easier debugging.

Dependencies

• This story is part of the epic SRVKP-8058: Tekton Hub Deprecation.
• The urgency depends on the final shutdown date for the Tekton Hub API. An extension to the end of 2025 is being requested upstream.
• Depends on the stability and public availability of the ArtifactHub API for Tekton tasks.

Acceptance Criteria (Mandatory)

• Given a `PipelineRun` that references a task from Tekton Hub by name (e.g., `taskRef: { name: "git-clone", kind: "Task" }

  `).

• When the `PipelineRun` is executed by PaC.
• Then the task is successfully resolved from ArtifactHub and the `PipelineRun` executes without error.
• This behavior must work correctly both before and after the `hub.tekton.dev` API is shut down.
• PaC logs clearly state that the task was resolved using ArtifactHub (e.g., "Resolved task 'git-clone' from ArtifactHub").
• The implementation includes comprehensive unit and integration tests for the new ArtifactHub resolution logic.
• (Optional) PaC can post a warning comment on pull requests that use a Hub task, informing the user about the deprecation and that the resolution is being handled, while recommending a future migration to resolvers.

INVEST Checklist

( ) Dependencies identified
( ) Blockers noted and expected delivery timelines set
( ) Design is implementable
( ) Acceptance criteria agreed upon
( ) Story estimated

Legend

( ) Unknown
( ) Verified
( ) Unsatisfied

Done Checklist

( ) Code is completed, reviewed, documented and checked in
( ) Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
( ) Continuous Delivery pipeline(s) is able to proceed with new code included
( ) Customer facing documentation, API docs etc. are produced/updated, reviewed and published
( ) Acceptance criteria are met