[Product Update] New Step Output UI

As part of improving the resiliency, scalability and quality of the CircleCI platform, CircleCI has updated the underlying systems that handle how “steps” make it to from the agents that execute work on compute to CircleCI’s storage systems and eventually to the CircleCI UI.

As part of this change, the terminal shown in the UI is being replaced with Xterm.js, a framework used by VS Code, Eclipse, and other common developer tools.

Benefits for users:

  • Increased reliability of CircleCI’s platform
  • New UI:
    • Vastly improved performance and rendering quality / robustness.
    • No cap on log output in the UI
    • Terminal control codes are now processed in the UI
    • URLs are clickable from the step output UI

CircleCI projects will be gradually migrated starting June 23, 2023. If you have any feedback or concerns with the new step output UI, please comment here.

New step output UI examples (better rendering of tables, clickable links, ansci escape codes)

This update is visually lovely, but it has removed the ability to search the step output text, which is a significant frustration for larger monorepo projects.

@mgabeler-lee-6rs the search functionality is a little different but it should still work. cmd/ctrl+f should take you to the search box for the open step. Or you can manually open a search box by clicking on the magnifying glass.

Are you referring to a different kind of search functionality?

Nope, that’s what I’m referring to. It does not find any text inside the canvas elements.

Correction – ctrl-f opens the browser page search most of the time for me. the custom step search only opens on ctrl-f if I click in the canvas first. confusing.

Odd, I can try to check with the team to see if that’s expected or not. One clarifying question, is the only difference clicking on the canvas page? Or are you also “expanding” a step? (clicking on the name of the step to open up the terminal output).

Yeah, it seems to have to do with where “focus” is after expanding a step. When I first expand it, or if I explicitly click inside it after expanding, focus is in there and ctrl-f redirects to the special search for that single step. But if I say click outside it so the scroll wheel scrolls the page instead of the step (which I personally do a LOT), then ctrl-f goes back to the browser find that can’t search the canvas contents.

This also means that, if I wanted to, I’d be unable to search in multiple step outputs at once, but that’s less of a concern.

Did this change the API responses for step output? I have some scripts which parse step output and they are now failing to parse outputs.

I think I was using an undocumented job step output API, but I’ll share the details in case anyone else was as well:


It looks like console coloring characters are now being returned in this response. e.g. \x1b[0m.

I’m now stripping them out and my scripts and they are working again.

@mgabeler-lee-6rs Thanks for the clarity, I’m talking with my Design & UX team to see what makes the most sense for behavior.

@TaxBusby Apologies for that “breaking change”. We have indeed stopped removing escape characters, so that would explain what you are seeing. Let me know if you run into any other additional issues and I’ll make sure to communicate changes like this ahead of time going forward.


What is the status of the rollout? We are waiting for the clickable link since few month and at the moment, it is still not clickable.


@benoittgt it’s currently rolled out to ~30% of all projects across our user base. If you send me a list of projects, I can opt those in right now. Feel free to send them to sebastian @ circleci.com

1 Like

Another issue I’ve found with this: it has broken the ability to view step output during execution from the VSCode extension. Output from completed steps is visible, but the currently running step displays nothing.

@mgabeler-lee-6rs thanks for raising that. Checking with the team that owns the VSCode extension on that.

One more issue with the “find text in step output” – the “custom” find tool works in the normal job view, but it’s absent from the single-step view (/pipelines/PROVIDER/ORG/REPO/N/workflows/U/jobs/N/parallel-runs/N/steps/N-N), which makes text search there impossible right now

@mgabeler-lee-6rs Good find, working with the team on an action plan.

Also regarding viewing live output via the VSCode extension, we are planning on fixing that. I’ll update here when it’s fixed.


I’m curious if this will help by supporting more / extended terminal colors (see Inspec terminal coloring, for example)?

I sent you an email - thanks for the offer of enabling it early for specific projects.

ps – Can confirm that it resolved some longstanding terminal issues with CLI output that uses extended colors :tada:

1 Like

Mentioned this on email too, but one minor (but annoying) thing I’m noticing (maybe the VSCode connection) is that there’s often an extra empty line at the end of the output on certain steps (maybe CRLF getting rendered at the end). I can confirm that locally, there’s no extra line in the output.



Happens on some of the builtin steps too.

@wyardley taking a look at that extra line with the team now. It might be expected behavior as most tools tend to end their output with a new line…but I’m double checking.

@mgabeler-lee-6rs single-step view should have search now enabled. Let me know if you run into any other additional issues, appreciate the feedback.