Capture User Information with PipelineRun/TaskRun Creation

[danielhelfand]

This issue was originally opened in the CLI repo for being able to see information about which user started a TaskRun/PipelineRun as part of running a tkn pipelinerun describe or tkn taskrun describe.

I am wondering if it makes sense to have a way to capture this information as part of TaskRuns/PipelineRuns by adding this information to the PipelineRunSpec/TaskRunSpec.

As far as how this user information would be captured, the CLI/Dashboard could probably do this fairly easily by capturing the user information and adding it to the PipelineRun/TaskRun, but there would be use cases where it would be difficult to enforce this (e.g., creating a PipelineRun/TaskRun using kubectl or events with triggering).

[danielhelfand]

/kind feature

[bobcatfish]

@danielhelfand when you say "user" what would that mean in this case? e.g. would it be the user signed in on the machine that is running the CLI commands?

[danielhelfand]

@bobcatfish We had a pretty good explanation in the CLI issue in this comment. The idea here would be about whoever is authenticated to the cluster and issuing a start of a TaskRun/PipelineRun. In the case of the CLI, it would be whoever is running it locally.

I think, at the very least, the goal is a way for this information to be included if someone wanted to monitor who started certain runs. Whether or not Tekton should actually handle all this for whoever is running Tekton is a fair question to ask, but perhaps there should be a way to capture this data coming from various sources.

[vdemeester]

This is kinda linked to #2201, or #2100 and part of #1839 (not the "version" of the resource themselves, but…)

[vdemeester]

This is also linked to #994

[vdemeester]

@danielhelfand are #2489 and #2444 closing this issue ?

[danielhelfand]

I think what's missing is how to include user information associated with a TaskRun or PipelineRun. Not sure what the best approach for that would be as far as if an additional property should be specified or maybe labels would be a better approach, and it would fall on client tools to label runs with appropriate user info?

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

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.

[vdemeester]

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

[tekton-robot]

@vdemeester: Reopened this issue.

In response to this:

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

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.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[vdemeester]

/remove-lifecycle stale

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

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.