number of steps in pipeline runs view

[didier-durand]

Hello,

Possible to add the number of steps executed in pipeline run view?

I'd see it for example before or after "Duration" in screenshot below. Maybe they should be displayed as X/Y where X is the number of successful steps and Y the total.

Thanks!

Didier

[AlanGreene]

Thanks for the request @didier-durand. We already provide this information in a number of places.

This is the same message displayed on the PipelineRun details page

The message comes from the PipelineRun status field:

$ kubectl get -ojson pr check-pr-labels-rf8nw | jq '.status.conditions[0].message'
"Tasks Completed: 1 (Failed: 0, Cancelled 0), Skipped: 0"

Is this sufficient for your needs or are you looking for a more prominent display of this information on the PipelineRuns list specifically?

[didier-durand]

Hi @AlanGreene,

I have seen that I can zoom on a PipelineRun via a click to get a list of tasks that were run as part of this pipeline. It's ok when you have a few pipelines. But, when you've many of them, you want a synthetic view of each pipeline at top level. That's why I believe that the PipelineRuns view should also provide the total number of tasks and the successful ones at top level in the dashboard : you want to make most efficient for DevOps teams.

If I may, I would also suggest some improvements for the task view when you click on a given PipelineRun: I would suggest something very much like display of tracing spans by Jaeger with time axis as horizontal as tasks represented on this time axis according to their start and stop time to provide a view where tasks are positionned on the time line.

Didier

[AlanGreene]

Note to self / future developers: Also relevant here is some of the previous discussion / design exploration around presentation of the status and status message: #775 and other issues. This might be a good opportunity to revisit this and see what additional information would make sense here and how best it can be displayed without making the list views overly busy.

@didier-durand can you expand on your second point about the 'tracing spans'? We're planning a PipelineRun visualisation which would show the directed acyclic graph generated by the Pipeline execution. This would be similar in function to visualisations provided in many other CD/CI tools.

Do you see the 'tracing spans' fulfilling a similar function? What additional / alternative benefit do they provide? How would a user make use of them? I'd love to understand this better so we can make more informed decisions about the future designs for the Dashboard.

[didier-durand]

@AlanGreene : I have seen the PipelineRun visualisation that you prepare. It is clearly a good thing to show a pipeline as a DAG. My point is different and complementary: basically, I suggest to add a time axis to the DAG in order to see how long after start a Task X was started and how much it lasted.

That is the reason of my analogy with distributed trace spans

In the above image, you can see when an additional trace happens and how long the interaction lasts.

That's what I would like to see in Tekton UI in order to spot easily the tasks that make the pipeline run for (too) long.

In your current DAG view, you can probably achieve that by correlating the length of the arrow with the delay until start and the length of the box with the task duration.

If I remain unclear, please, don't hesitate to ask additional questions

Didier

[AlanGreene]

Thanks for the additional information, that helps to understand a possible use case for something like this.

[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.

[didier-durand]

@AlanGreene : any progress / decision regarding the implementation of this use case? Best,Didier

[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.