• Proposed title of this feature request
  RFE - implement displayName of tasks in webconsole
• What is the nature and description of the request?
  implement the usage of the displayName parameters of taskRun in the openshift webconsole
• Why does the customer need this? (List the business requirements here)
  it's already implemented in the tektonDashboard

since openshift-pipeline 1.13, we can use displayName. Doc says:

"With this update, when specifying a task and using the displayName parameter, you can use parameters that include the values of parameters, results, or context variables in the display name, for example, $(params.application), $(tasks.scan.results.report), $(context.pipeline.name)"

However, this parameters is not visible in the openshift webconsole. This RFE is to add this feature.

Goals

< Who benefits from this feature, and how? What is the difference between today’s current state and a world with this feature? >

Requirements

• • (Optional) Use Cases

< What are we making, for who, and why/what problem are we solving?>

Out of scope

<Defines what is not included in this story>

Dependencies

< Link or at least explain any known dependencies. >

Background, and strategic fit

< What does the person writing code, testing, documenting need to know? >

Assumptions

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Customer Considerations

< Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

Documentation Considerations

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

What does success look like?

< Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

QE Contact

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Impact

< If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

<links>

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment