TEP-0047: Pipeline Task Display Name

[itewk]

adding a new TEP for Pipeline task display name.

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Ian Tewksbury (b95b605)

[vdemeester]

/kind tep

[pritidesai]

thanks @itewk for the all the updates, looks good to me.

You will have to squash all the commits into one and pick up a TEP number based on the instructions here before we can merge this.

Also, just spelling it out, this TEP is proposing an API change in pipeline and the changes can be picked up by CLI/Dashboard once it's available (to display human readable pipelineTask names if specified).

[itewk]

thanks @itewk for the all the updates, looks good to me.

You will have to squash all the commits into one and pick up a TEP number based on the instructions here before we can merge this.

@pritidesai done

[pritidesai]

thanks 🙏

/lgtm

(we already have one more TEP with 0046 #318 😄 ). You might have to bump your TEP number.

[itewk]

thanks 🙏

/lgtm

(we already have one more TEP with 0046 #318 😄 ). You might have to bump your TEP number.

@pritidesai should i bump it now? i had used the script to have it calculate the number, but i suppose that doesn't take into account other in progress PRs.

[pritidesai]

@pritidesai should i bump it now? i had used the script to have it calculate the number, but i suppose that doesn't take into account other in progress PRs.

yes please if you can, that would be great 🙏

[chmouel]

/lgtm

[itewk]

@pritidesai updated the TEP number as requested and re-based

[ghost]

We already have Pipeline.spec.description (and similar in other resources) added by tektoncd/pipeline#2089, and taskSpec.metadata for inline TaskSpecs in PipelineTasks added by tektoncd/pipeline#2826, so are we proposing to replace these? It would be a breaking change, but possibly one worth making for consistency.

I think this sounds like a pro in favor of Possible solution 1? - Suggest adding something like "since we have established fields like pipeline.spec.description that perform similar function we continue that pattern with new fields such as pipeline.spec.tasks[*].displayName"

And also possibly a con against Possible solution 2? - Suggest adding something like "moving to annotations may mean we need to deprecate the existing description fields like pipeline.spec.description to avoid confusion and duplicate functionality".

We'll have to do some legwork here when taking the TEP to implementable to assess which route (or a completely different one entirely) is ultimately best to go down.

[itewk]

@sbwsg @AlanGreene sooo....should I be updating the TEP in some way in order to get it merged in?

[itewk]

rebased on latest from main

[ghost]

@sbwsg @AlanGreene sooo....should I be updating the TEP in some way in order to get it merged in?

Probably the quickest way to get this merged would be to remove any mention of implemention. Remove possible solution 1, possible solution 2. Remove mention of specific field names such as pipeline.spec.tasks[*].displayName. Just reduce the doc to its problem statement. It will then be the responsibility of whoever takes this TEP to implementable status to figure out the implementation they want to move forward with.

[ghost]

(But even after making those changes you'll still need two reviewers to agree that the TEP is mergeable. I'm just saying what I would lgtm from my perspective. Another reviewer may see things differently.)

[itewk]

@sbwsg @AlanGreene @chmouel @pritidesai i'm confused, because the template explicitly calls out putting in suggestions for implementation, isn't that what they are exactly, just suggestions, and then whoever implements can do whatever ends up making sense? If you all want me to remove the suggestions I will. It seems everyone agrees this feature is needed, however its implemented, I am looking to the smoothest path to at least have it on the road map.

[ghost]

It seems everyone agrees this feature is needed, however its implemented

Right, this is what I'm suggesting we reduce the TEP to - the parts folks agree on.

With suggested implementations, as reviewers we have to figure out whether they're workable and what trade-offs we make in the system's design as a result. It looks like most of the sticking points here are centered on those suggestions, hence my proposal to remove them entirely. Again, other folks may feel differently and I'd like to hear from them because my read of all this could be entirely off base.

[itewk]

@sbwsg understood.

@AlanGreene @chmouel @pritidesai what are your all thoughts? should i remove any suggestion for specific implementation to be able to merge, or are you all ready to review and merge as is?

[AlanGreene]

We all seem to agree this is something that's needed / worth doing, but there's still some work to be done around the proposed implementation. I'd be on board with @sbwsg's suggestion to remove the implementation details for now to get the TEP merged.

[itewk]

@sbwsg @AlanGreene removed any implementation suggestions and re-based.

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbwsg

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

The pull request process is described here

Needs approval from an approver in each of these files:

• teps/OWNERS [sbwsg]

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

[ghost]

@AlanGreene @pritidesai this TEP looks ready to merge to my 👀 . What do you folks think?

[AlanGreene]

/lgtm

[itewk]

wahooo!!! thanks everyone