Add --resolvertype flag to rerun a resolver based pipelinerun by pratap0007 · Pull Request #2615 · tektoncd/cli

pratap0007 · 2025-09-25T19:05:51Z

Previously, the tkn p start <pipeline_name> --last command was used to rerun a pipeline by referencing the last successful PipelineRun. This worked well for pipelines that were defined and available on the cluster (i.e., when the Pipeline resource existed in the cluster).
However, with resolver-based pipelines, the pipeline definition is not stored as a cluster-scoped resource. Instead, it is dynamically fetched from an external source, such as:

Git resolver – when the pipeline is defined in a Git repository
HTTP resolver – when the pipeline is fetched from a remote HTTP endpoint
Hub resolver – when the pipeline comes from Tekton or Artifact Hub
Bundle resolver – when the pipeline is packaged and retrieved from an OCI bundle
Cluster resolver – when it references a resource within the cluster using the resolver mechanism

Because of this, the existing --last flag did not work for resolver-based pipelines — the CLI had no direct reference to the original resolver configuration (e.g., URL, repository, bundle reference, etc.) used in the previous run.

To address this limitation, this PR introduces a new flag called --resolvertype.
This flag allows users to specify the resolver type (such as git, http, hub, cluster, bundle, and a special type remote resolvers (whan user doesn't know about resolver type they can specify --resolvertype=remote which would be any supported type resolver)) when re-running a resolver-based pipeline.

When provided, the CLI uses the metadata from the last PipelineRun — including the resolver type and its parameters — to reconstruct and trigger a new PipelineRun using the same remote source.

This PR supports these following combinations of flag --last and --resolvertype

tkn p <pipeline_name> start –last (existing one)
tkn p start <pipeline_name> --last –remotetype=remote
- pipeline_name is optional and
- If provides pipeline_name is provided then it searches pipeline on the cluster
tkn p start <pipeline_name> –resolvertype=git/http/bundle/cluster/hub
- pipeline_name is required
tkn p start <pipeline_name> –last –remotetype=git/htttp/cluster/bundle/hub
- pipeline_name is optional
- if pipeline_name is provided then it searches pipeline on the cluster

closes: #2422

Changes

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

Includes tests (if functionality changed/added)
Run the code checkers with make check
Regenerate the manpages, docs and go formatting with make generated
Commit messages follow commit message best practices

See the contribution guide
for more details.

Release Notes

This introduces a new flag called `--resolvertype`. This flag allows users to specify the resolver type (such as `git`, `http`, `hub`, `cluster`, `bundle`, and a special type `remote` resolvers (which would be any supported type resolver)) when re-running a resolver-based pipeline.

pratap0007 · 2025-09-29T06:39:46Z

/assign @chmouel @divyansh42

chmouel · 2025-09-29T08:03:12Z

pkg/cmd/pipeline/start.go

+	return opt.runWithResolverOnly(cs, pipelineName)
+}
+
+func (opt *startOptions) runWithResolverOnly(_ *cli.Clients, pipelineName string) error {


all those methods have a lot of duplications.. any way to streamline this ? by extracting it to a helper method like createObjectMeta(lastPipelineRun, prefixName)

sure, I update it by extracting those in a helper function

waveywaves · 2025-10-01T06:15:34Z

/retest

waveywaves · 2025-10-01T07:32:07Z

/assign

waveywaves · 2025-10-01T07:11:23Z

pkg/cmd/pipeline/start.go

+
+			// Validate resolvertype values
+			if opt.ResolverType != "" {
+				validResolvers := []string{"hub", "git", "http", "cluster", "bundles", "remote"}


change to "bundle" resolver and not bundles

waveywaves · 2025-10-01T07:12:21Z

docs/cmd/tkn_pipeline_start.md

      --pipeline-timeout string       timeout for PipelineRun
      --pod-template string           local or remote file containing a PodTemplate definition
      --prefix-name string            specify a prefix for the PipelineRun name (must be lowercase alphanumeric characters)
+      --resolvertype string           resolver type for remote pipelines (hub, git, http, cluster, bundles, remote)


if I am not wrong this is "bundle" resolver and not bundles

I checked the documents and saw pipelineRef.resolver is bundles , should we change it bundle?

waveywaves · 2025-10-01T07:12:42Z

docs/man/man1/tkn-pipeline-start.1


+.PP
+\fB\-\-resolvertype\fP=""
+    resolver type for remote pipelines (hub, git, http, cluster, bundles, remote)


bundle and not bundles

waveywaves · 2025-10-01T07:13:32Z

pkg/cmd/pipeline/start.go

+	return opt.runWithResolverOnly(cs, pipelineName)
+}
+
+func (opt *startOptions) runWithResolverOnly(_ *cli.Clients, pipelineName string) error {


waveywaves · 2025-10-01T07:18:21Z

pkg/cmd/pipeline/start.go

+
+ Re-run the last PipelineRun that used git resolver
+
+    tkn pipeline start --last --resolvertype=git -n bar


no pipeline name given

here, pipeline name is optional

waveywaves · 2025-10-01T07:20:54Z

pkg/cmd/pipeline/start_test.go

 	test.AssertOutput(t, expected, got)
 }
+
+func TestPipelineStart_WithResolver(t *testing.T) {


This is testing specifically with git resolver so should be named WithGitResolver

pratap0007 · 2025-10-22T12:13:10Z

/retest

- Add --resolvertype flag supporting hub, git, http, cluster, bundle and remote resolver type - Implement special remote resolver that finds latest PipelineRun with any resolver type and rerun it - If --resolvertype flag value is except remote, filters pipelinerun by that resolver type - Integrate --resolvertype with existing --last flag functionality - With --resolvertype and --last flags pipeline name is optional - With --last flag pipeline name is optional - Add validation: resolvertype requires pipeline name except for remote type - Support all flag combinations: --resolvertype only, --last only, both together - Include the unit tests closes: tektoncd#2422 Signed-off-by: Shiv Verma <[email protected]>

pratap0007 · 2025-10-23T14:11:39Z

@chmouel I have updated the PR. Could you please review it again?

chmouel · 2025-10-31T08:18:16Z

/lgtm

tekton-robot · 2025-10-31T08:18:41Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: chmouel

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [chmouel]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

tekton-robot added the release-note Denotes a PR that will be considered when it comes time to generate release notes. label Sep 25, 2025

tekton-robot requested review from divyansh42 and pradeepitm12 September 25, 2025 19:05

tekton-robot added the size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. label Sep 25, 2025

pratap0007 force-pushed the rerun-pr branch from 32a46eb to da400b4 Compare September 25, 2025 19:34

tekton-robot assigned chmouel and divyansh42 Sep 29, 2025

chmouel reviewed Sep 29, 2025

View reviewed changes

tekton-robot assigned waveywaves Oct 1, 2025

waveywaves suggested changes Oct 6, 2025

View reviewed changes

pratap0007 force-pushed the rerun-pr branch from 1fa2b7a to 4cdf50f Compare October 22, 2025 02:34

pratap0007 force-pushed the rerun-pr branch from 4cdf50f to 41874f4 Compare October 23, 2025 00:09

tekton-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Oct 23, 2025

tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Oct 31, 2025

chmouel approved these changes Oct 31, 2025

View reviewed changes

tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 31, 2025

tekton-robot merged commit 39c9c6d into tektoncd:main Oct 31, 2025
11 checks passed

BrewTestBot mentioned this pull request Nov 20, 2025

tektoncd-cli 0.43.0 Homebrew/homebrew-core#255302

Merged


		Re-run the last PipelineRun that used git resolver

		tkn pipeline start --last --resolvertype=git -n bar

Conversation

pratap0007 commented Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Submitter Checklist

Release Notes

Uh oh!

pratap0007 commented Sep 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

waveywaves commented Oct 1, 2025

Uh oh!

waveywaves commented Oct 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pratap0007 commented Oct 22, 2025

Uh oh!

pratap0007 commented Oct 23, 2025

Uh oh!

chmouel commented Oct 31, 2025

Uh oh!

tekton-robot commented Oct 31, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

pratap0007 commented Sep 25, 2025 •

edited

Loading