Git resource logs are not surfaced so Pipeline fails with no logs

[jessm12]

Expected Behavior

If there is a problem in accessing the Git repo that has been defined in the Git PipelineResource (this is reported in one of the init containers that runs before any defined tasks for mounting resources) this should be surfaced in the PipelineRun details/logs to show what went wrong e.g. credentials weren't valid or the repo doesn't exist

Actual Behavior

What is actually shown is a strange combination of a PipelineRun whose task reports as succeeding but with no logs and a failed overall view

Steps to Reproduce the Problem

1. Create a PipelineRun with associated PipelineResource but use an invalid repo or have lacking credentials to access the repo
2. Navigate to the PipelineRun page and observe the above

[carlos-logro]

/assign @carlos-logro

[carlos-logro]

After investigating the reason behind the logs not being shown, I found out that some of the steps are being filtered in the PipelineRun container when the loadTaskRuns fn is called:

loadTaskRuns = (pipelineRun, taskRunNames) => {

    let runs = taskRunNames.map(taskRunName =>
      getTaskRun(store.getState(), { name: taskRunName })
    );

    const {
      status: { taskRuns: taskRunDetails }
    } = pipelineRun;

    runs = runs.map(taskRun => {
      const taskName = taskRun.spec.taskRef.name;
      const task = selectedTask(taskName, this.props.tasks);
      const taskRunName = taskRun.metadata.name;
      const { reason, status: succeeded } = getStatus(taskRun);
      const { pipelineTaskName } = taskRunDetails[taskRunName];
      const steps = stepsStatus(task.spec.steps, taskRun.status.steps);
      return {
        id: taskRun.metadata.uid,
        pipelineTaskName,
        pod: taskRun.status.podName,
        reason,
        steps,
        succeeded,
        taskName,
        taskRunName
      };
    });

    return runs;
  };

The filtering part is done with the help of the stepsStatus util fn:

export function stepsStatus(taskSteps, taskRunStepsStatus = []) {
  const steps = taskSteps.map(step => {
    const stepStatus =
      taskRunStepsStatus.find(status => status.name === step.name) || {};

    let status;
    let reason;
    if (stepStatus.terminated) {
      status = 'terminated';
      ({ reason } = stepStatus.terminated);
    } else if (stepStatus.running) {
      status = 'running';
    } else if (stepStatus.waiting) {
      status = 'waiting';
    }

    return {
      ...step,
      reason,
      status,
      stepStatus,
      stepName: step.name,
      id: step.name
    };
  });
  return steps;
}

Apparently the filtered steps were the ones containing the errors logs so to show all the steps I just made this simple edit to the util fn:

export function stepsStatus(taskSteps, taskRunStepsStatus = []) {
  // const steps = taskSteps.map(step => {
  const steps = taskRunStepsStatus.map(step => {
    // const stepStatus =
    //   taskRunStepsStatus.find(status => status.name === step.name) || {};
    const stepStatus = step;

    let status;
    let reason;
    if (stepStatus.terminated) {
      status = 'terminated';
      ({ reason } = stepStatus.terminated);
    } else if (stepStatus.running) {
      status = 'running';
    } else if (stepStatus.waiting) {
      status = 'waiting';
    }

    return {
      ...step,
      reason,
      status,
      stepStatus,
      stepName: step.name,
      id: step.name
    };
  });
  return steps;
}

which results in:

@AlanGreene, as you can see now all the steps are shown but the log message is too raw to be readable, also in this particular case, the selected step name is too long & lastly, the steps after the fail one have an 'OK' state but they actually never ran so I think we should add a state that is neither 'OK' nor failed probably a warning or something, if possible.

[AlanGreene]

The Step component already has support for multiple states other than success / error, see the storybook for details https://alangreene.github.io/dashboard/?path=/story/step--default
We just need to ensure the correct props are being provided.

As far as I remember the reason for using the taskSteps instead of the taskRunSteps was so that we could display entries in the tree before the corresponding TaskRuns had actually been created.

[carlos-logro]

I propose we keep the logic it has right now but double check the taskRunSteps array to see if one of the elements has an error & if that so then include in the task tree if not then omit it like its been doing. what do you guys think??

[AlanGreene]

/assign