Description of problem:

After upgrading to Pipelines 1.20.2, using custom hub catalog annotations with version specifiers causes an "invalid port" error. When a pipeline
annotation uses the format catalog://resource:version (e.g., foo://python-build-test-tag-foo:1.2), Go's url.Parse() interprets the
:1.2 portion as a port number rather than a version separator.

The pipeline itself is fetched correctly via getRemote() in annotation_tasks_install.go which uses strings.Split(uri, "://"). The error
occurs later when assembleTaskFQDNs() in pkg/resolve/remote.go tries to use the same catalog reference as a base URL for resolving relative
task paths.

This blocks customers using custom TektonHub catalogs with versioned pipeline references.

Parent ticket: SRVKP-9416
Slack thread: Support thread

Prerequisites (if any, like setup, operators/versions):

OpenShift Pipelines 1.20.2
Custom hub catalog configured via TektonConfig:

catalog-1-id: foo
catalog-1-name: foo
catalog-1-url: <https://tekton-hub-api.apps.foonet/v1>
catalog-1-type: tektonhub

Pipeline annotation using catalog://resource:version format

Steps to Reproduce

Configure a custom TektonHub catalog in TektonConfig settings

Create a PipelineRun with annotation: pipelinesascode.tekton.dev/pipeline: "foo://python-build-test-tag-foo:1.2"

The pipeline should reference tasks via pipeline annotations

Trigger the PipelineRun via a push or pull request event

Actual results:

PipelineRun fails with error:

parse "test://python-build-test-tag-test:1.2": invalid port ":1.2" after host

The assembleTaskFQDNs() function in pkg/resolve/remote.go passes the custom hub URL (e.g., foo://python-build-test-tag-foo:1.2) to Go's
url.Parse(), which interprets :1.2 as an invalid port number.

Expected results:

Custom hub catalog references should not be parsed as HTTP URLs. The assembleTaskFQDNs() function should only attempt URL-based relative task
resolution for http:// and https:// pipeline URLs. Hub catalog references (catalog://resource:version) should pass tasks through unchanged
since relative path resolution is meaningless for hub schemes.

Reproducibility (Always/Intermittent/Only Once):

Always - occurs every time a custom hub catalog reference with a version specifier is used in a pipeline annotation when that pipeline also has task
annotations.

Acceptance criteria:

Custom hub catalog references (e.g., foo://pipeline:1.2) do not cause "invalid port" errors
assembleTaskFQDNs() skips URL parsing for non-HTTP(S) schemes and returns tasks unchanged
HTTP and HTTPS pipeline URLs continue to resolve relative task paths correctly
Unit tests cover hub catalog URLs, custom hub without version, empty URL, and HTTP/HTTPS URLs

Definition of Done:

Fix merged and passing CI
Unit tests added for all scheme variants
No regression in existing relative task resolution for HTTP(S) URLs

Workaround:

Use direct HTTPS URLs in pipeline annotations instead of hub catalog references:

 pipelinesascode.tekton.dev/pipeline: "<https://tekton-hub-api/v1/resource/foo/pipeline/check-pac-foo/1.0/raw>"
 

Additional info (Such as Logs, Screenshots, etc):

Full error from controller logs:

 {"level":"error","ts":"2026-02-17T06:41:23.462Z","logger":"pipelinesascode","caller":"events/emit.go:49","msg":"an error occurred: parse
 "test://python-build-test-tag-test:1.2": invalid port ":1.2" after host","commit":"12233","provider":"bitbucket-datacenter","event-id":"0cd8d1af-3333-
 4600-444-e1fffa1be028","event-sha":"333","event-type":"push","source-repo-url":"<https://git/projects/OPENSHIFT/repos/test-checker-app","tar>
 get-branch":"refs/heads/sbe/supply-chain-security","namespace":"col-tekton-test"}
 

Fix is in pkg/resolve/remote.go, function assembleTaskFQDNs() — add early return for non-HTTP(S) schemes before calling url.Parse().