Dashboard: PipelineRun component fatally errors if no name found during loadTaskRuns

Created on 14 Oct 2019  路  9Comments  路  Source: tektoncd/dashboard

Expected Behavior

Suppose to render either showing error or details of the PipelineRun

Actual Behavior

Page broken completely.
Some logs show that the page had an error fetching the PipelineRun at the beginning but apparently it later succeeded although by that time the page was already broken.
Screen Shot 2019-10-14 at 11 08 20 AM

Steps to Reproduce the Problem

  1. Trigger PipelineRun via Webhook
  2. Wait for PipelineRun to finish.
  3. Click PipelineRun

Additional Info

This is only happening with a successful PipelineRun that was triggered via webhook. I have another PipelineRun that was triggered when Importing Resources & I am able to see its details and logs.

kinbug

Most helpful comment

@a-roberts im pretty sure after the PR I have open is merged the issue will be fixed.

All 9 comments

I've been in this code before when I was in rebuild and I added hardening as sometimes the fields weren't yet coming back over the websocket, may need the same kind of fix (if it's null, just render nothing for now - just for the name - then eventually we get the data over the websocket and the component can be fulfilled)

I'll go for the reproduce first.

I've done five PipelineRuns triggered from a webhook with no problems - for a case where I didn't even create a secret.

image

I would prefer for the steps to be red and not green - the build step, for example, failed with:

{"level":"error","ts":1571307049.0442152,"logger":"fallback-logger","caller":"git/git.go:35","msg":"Error running git [checkout1392b79839a984b0acff54a56dff1262ab1b5533]: exit status 128\nfatal: reference is not a tree: 

but that's a different issue entirely, quite possibly https://github.com/tektoncd/dashboard/issues/644

So I created a secret to make sure it's an entirely successful PipelineRun, and all is well. Even with many many many refreshes. I'm wondering if this is due to accessing the page too quickly before enough data's sent over the websocket for the PipelineRun, going for the reproduce still.
.

@carlos-logro I'm going to park this one in favour of OpenShift 4.2 support work for now, I've pinged you asking for more details on a reproduce - lemme know please

I talked briefly with Adam & Carlos about this, and just wanted to document here. I am also seeing this issue, and it seems to be occurring when a Condition task fails in the PipelineRun.

This remains parked so I'm officially unassigning myself, plenty of juicy info here though should anyone wish to take over (I'm swamped with OpenShift 4.2 work for an imminent release and it's proving challenging), I'll top of the backlog it too

@a-roberts im pretty sure after the PR I have open is merged the issue will be fixed.

/assign

My PR has been merged and thus unassigning myself.
/unassign

Closing due to the PR being in and we reckon this is fixed

Was this page helpful?
0 / 5 - 0 ratings