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?
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.
@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.
@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
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.
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
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.
@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.
