[RFC] Label user errors for failed PipelineRun status in user-facing messages

[JeromeJu]

Changes

This commit labels the user errors for failed PipelineRun status. This aims to communicate explicitly with users of whether the run failed due to a user error or not.

This is a step 1 for #6859

part of #7276

/kind misc

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
• Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

NONE

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign pritidesai after the PR has been reviewed.
You can assign the PR to them by writing /assign @pritidesai in a comment when ready.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	89.5%	87.9%	-1.7

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	89.5%	87.9%	-1.7

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	89.5%	92.5%	3.0

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	89.5%	92.5%	3.0

[dibyom]

instead of passing in a boolean at the call site, could we wrap the errs or the reasons into an user error type?

[JeromeJu]

Thanks Dibyo! There seems to be two questions that needs to be filled in:

1. Shall we use bool or wrapping with a new error?

• Set isUserError as a bool flag, and add it to the pipelineRun.MarkFailed() as a parameter. This will force our contributors to explicitly call out whether this is a user error or not when adding to the reconciler logics.
• Introduce a new error "userError". Wrap the error message with it and at pipelineRun.MarkFailed(), label user using regex to check the error message. However, it is hard to tell if the error introduced is used or not.

2. Do we want to label on TaskRun/PipelineRun reason or message?
   After examining the error messages, we have use cases where a TaskRun/PipelineRun reason has many different error messages i.e. PipelineRunReasonFailedValidation. It might be more precise to label error messages.

[JeromeJu]

Thanks for the discussion offline.
I think the way forward should be doing both adding a bool flag so that we can leverage judgement from the author and creating a new error type UserError.

[tekton-robot]

@JeromeJu: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[JeromeJu]

closed in light of #7475