I just opened CircleCI and received the new pipeline view, and thought I’d let you know my thoughts on it. My usual workflow for checking circle-ci is when a build fails. Let’s walk through it as an example:
Old UI:
- Open pipelines page (I normally have this open in a pinned browser tab at all times)
- See which pipeline failed, why it triggered, and whether it took too much time (indication that this is a flaky hang, not a real build issue. We have those regularly, but haven’t managed to reproduce them outside CircleCI).
- If it’s a flaky hang, click the rerun from failed icon. (Done, and since I have auto-expand enabled, in a single click)
- If it’s not a flaky hang, click the relevant failed job. (Since I have auto-expand enabled, this is the first click)
- If it’s a test failure, click on the “Tests” tab (A useful feature would be that CirceCI would auto-open the “Tests” tab instead of the “Steps” tab if there are failing test results). And see which tests are failing. Then navigate back to the pipelines overview. (Done in three clicks)
- If it’s not a test failure, click the step, highlight the output, and paste it in VSCode (because of the long standing separate issue that log lines don’t render in CircleCI, but can still be selected and copied)
- Navigate back to the pipelines overview (so my pinned browser tab is ready for the next iteration)
- Read the log in VSCode and see what’s wrong. (Done in three clicks, and a copy-paste).
In summary, in the new UI, I’m most often finished in one, three or four clicks, and the level of information shown on the screens is in general appropriate for the level of nesting of the screens. When more information than might be expected is available (e.g. trigger, duration) that is useful information at that level.
New UI:
- Open pipelines page (I normally have this open in a pinned browser tab at all times)
- Click the row of the failed run. (This one click is now always needed). It automatically opens the first failed job (Great idea! This actually saves me a click sometimes)
- Check if the duration indicates a timeout. If so, click the rerun from failed button. Then click the back button to navigate back to the pipeline overview. (Done in three clicks whereas previously I’d be done in one click)
- If it wasn’t a timeout, and the failure was not a test failure, it’s likely that the log is already open in the right panel. Copy-paste it to VSCode to read it. Click back to go back to the main overview page. (Done in two clicks whereas previously this’d be three clicks. And a copy-paste)
- If it was a test failure, click the “Tests” tab and investigate what’s wrong, then click back to the overview page. (Done in three clicks, same as previously)
Summary
Overall, my workflow became simpler in more complex cases but more complex in simpler and more common cases. The UI became less gradually layered and I think it is harder to comprehend than previously, but some choices were clever (auto opening the failed job) and compensate.
Suggested changes
Personally I suggest these changes to the new UI:
- Duration should be put back in the overview row
- Trigger reason should be put back in the overview row
- Rerun / rerun from failed buttons should be put back in the overview row.
- I think the two-rows-per-row table layout is harder to parse than the previous single row layout, but it does look nicer, so that’s a bit of a subjective thing.
- The expand button in the overview row is completely wrong now since it doesn’t expand, but is one larger button with the icon, and also there’s not always an expand button (e.g. when not run) and then the icon column UI is wonky. This expand button should be removed entirely.
- The auto open of failed step is great. But it can be improved. If there are test results uploaded, and some of those failed, open the “Tests” tab instead of the “Steps” tab.