Where is the commit message? This is by far and away the best way to understand what a build is building, yet it is omitted. This is more should always be shown alongside the commit hash.
How about always expanding the most recently failed and any running pipelines by default? Save me doing it always.
Agreed! That is also our goal with the new UI with almost precisely that phrasing. Really appreciate that you shared such specific reasons we were not hitting that goal for you.
A few updates:
Keep the feedback coming. We are building this new UI with an iterative approach we call the WAFL (read more). It will continue to improve for you. As we iterate towards that goal above, we may accommodate some of these specific requests or we may find a faster way to serve the actual goal stated above.
Commit message is coming soon. We are building the new V2 Pipelines API as we build the Pipelines-based UI and we did not have that information available to us yet. Now that we do, we’ll get that implemented soon.
“Expanding the most recently failed and any running pipelines by default” is something we are discussing. What we don’t want is to slow page load time by needing more information for users that some don’t find necessary. But it is seeming you are correct that this is the most common path for users.
Your ideas for Builds/Tests (we call ‘Builds’ ‘Jobs’ now) are all also under consideration, though we will likely not execute on scrolling to failed step as we’ve also heard a lot of frustration about a page jumping on one’s behalf from developers. Would less vertical screen real-estate up top solve the problem just as well for you? Then you could see the failed step without scrolling as well.
Cheers and please keep letting us know your thoughts.
Sorry to harp on what others are saying, but this seems like the only way I can see to give feedback. The new UI drove me nuts because:
I can’t see Commit messages
The pipelines are not in the order they are running in (a pipeline that’s restarted may be way down the page and might be the next pipeline to run once a container frees up)
There’s no 1-click way (or even 2 click way on the same page) to get from the Pipelines page to the build log with the error (I’d like a link to the artifacts too, if I’m dreaming). I can get to the config file though in 2 clicks, which I’ve never needed to do ever.
On the Pipeline page, canceled jobs seem to not know they’re canceled until a new job is run
CTRL-F is broken on the build output page
I do LOVE that it’s super easy to see that somebody is running their build over and over to get a passing build. That’s a great feature. It should just move that whole pipeline block up though when somebody does that.
Thanks @rsshilli for chiming in. We agree with all 5 of these points.
#1 is being addressed as we speak, and have designs made for #3. #5 is something we must and will address before forcing this UI on users.
#2 and #4 are the hard ones. They each require changes to our new Pipelines API that we don’t have capacity for yet. But we’re aware of both and will address as time presents itself.
When I click on an artifact (and I often have to click on one for each test that failed), they open in the same tab now, instead of opening in new tabs like they did before. It’s MUCH better the old way (opening in a new tab).
AWS CodePipeline keeps trying to pull us in and CircleCI’s UI being soooo much better is what keeps us away. Please don’t force people to move over to the new UI until it’s ready. It’s your core strength.
Thanks for that last data point. We make a point in the new UI to not open new tabs whenever possible as most developers prefer to choose for themselves where a new tab opens. By having the baseline option open in the same tab, they can right-click to open on a new tab if preferable.
If we took care of all of your suggestions except this last one and pushing reran workflows to the top of the Pipelines page, would the new UI feel “ready” to you personally?
I recently re-wrote a log viewer and opted out of using a virtual scroller for these reasons. Every off the shelf implementation I evaluated was unsuitable for use as a log viewer for one reason or many. The amount of extra engineering required to get good search and text selection is simply not put into them, and starts to edge closer to a text viewer/editor.
So, I took control of the dom element and went the old fashion route. Performance is great to at least 100k+ lines and 30fps with a little care while populating it.
For me, for now and the foreseeable feature TBH, the legacy UI is the best workaround.
One frustrating thing I’ve just realised is that the new UI doesn’t work well if you modify the URL.
On the old UI I could be looking at the output of a particular build job, and if I wanted to go up to the list of jobs for the project I could press ⌘+l to hop into the address bar, remove the job ID from the URL and hit enter to jump to the list of builds. When I try this in the new UI it shows a 404 page.
i.e… Old job page https://circleci.com/gh/{github org}/{project}/{job ID} could be changed to https://circleci.com/gh/{github org}/{project}/.
But new job page https://app.circleci.com/jobs/github/{github org}/{project}/{job id} cannot be truncated to https://app.circleci.com/jobs/github/{github org}/{project}.
I can understand that a list of jobs across all pipelines might not be appropriate in the new UI, but it’d be good if it could redirect me to an equivalent page - maybe the pipeline list for the project?
EDIT: The context for this was that I was working on an outdated project and ended up on this page:
I just tried the new UI for the first time. One of the first things I noticed is that console output no longer show colors. This makes them much harder to read and quickly locate information.
I just tried out the new UI and like the poster above was disappointed to see that test console output no longer has colours. It’s so much nicer having the red/green visuals when skimming over test results.
A little context, we tried to give our users both fast page-load time and colorized output with React Virtualize. However, it broke their ability to use CMD+F which is core to the majority of user’s workflow in our UI. We pulled it, so CMD+F is back, but now we’re trying other approaches to increase page load time and get colorized output back. You will see it again before we shut off the old UI.
What’s the justification behind getting rid of the Insights pages and only offering the data through the CircleCI API going forward? I saw this post mentioning it, but didn’t understand why.
It was a useful feature and gave good at-a-glance info about the health of your projects’ builds. An API to get more in-depth info is nice, but I’m not sure why this (along with other features) are getting gutted as part of the new UI.
Am I the only one who thinks this new UI still isn’t ready? I have seen issues with the following:
Canceling a pipeline (or build or whatever) is still pretty weird and hard to do. Then new builds don’t start for a while? I updated this issue here with details: New UI experience has an issue with canceled jobs
There’s no 1 or 2 click way of properly canceling a pipeline. I’m not even clear the right way to do it. (also mentioned in the link above)
If I restart a job on a different page (ie. not in the top 20 pipelines) then it doesn’t bubble up to the top. (Related to issue #2 from my post in Dec '19).
Pipelines don’t know when they’re canceled. For example, this looks like 2 pipelines are running:
I really want a 1-click way from seeing a pipeline to getting to the logs. I only have 1 job in my workflow. The old UI allowed me to do that. This one makes me want to create my own simpler UI on top of it.
How do I opt-in back into the new UI after going back to the old UI to turn on pipelines for a project? It’s ridiculous that there isn’t a simple button to turn the new UI back on
Thanks. However, the banner is not always there. For example, earlier today when I wrote my question the button wasn’t there in any project I tried to access. In may be due to something in the precise order of actions I carry out, but it’s not always there.
Is there another way to opt back in?
Hey @amitz it should always be there if you’re viewing a pipelines-enabled project! You do have to navigate to a Job Detail page specifically, not a different page.
Perhaps it wasn’t there earlier because your project was not yet pipelines-enabled. The UI is incompatible with non-pipelines-enabled projects, but at this point 97% of builds are pipelines-enabled.
I think the issue might be that you have to navigate into the job details. I guess this isn’t intuitive since I found it hard to find earlier, even though I’ve done it numerous times in the last few months. The expected behavior would be to find it in the jobs list AND the workflows list and not only in the job details.
You should take into account that for a company like ours, we have numerous projects that are still not pipeline-enabled, because we haven’t touched them for a while. So I frequently encounter such a project and I want to enable pipelines for that project. The current experience is as follows:
Go to the project in the new UI.
Get the following message - We don’t have any Pipelines to show here.
Click the button “Enable Pipeline Processing”
(at this point I would expect pipeline processing to be enabled and be done with it, but that’s not the case, instead I get the following)
Redirected to the Project Settings in the new UI. I couldn’t find any way to enable pipeline processing in the new UI.
Navigate back to the Pipelines page in the new UI.
Locate the “Old Experience” button and click it. Essentially, at this point I’ve opted-out of the new UI - this is terrible.
Manually click Project Settings icon.
Manually click Advanced Settings
Scroll down to the bottom.
Turn on Pipelines for the project.
Go looking for the way to opt back into the new UI.
I’m pretty sure at this point you see what I mean and why a lot of us aren’t sure the new UI is ready for prime time.
Thank you for your feedback, we appreciate your passion for our product and will always continue to improve our UX.
At this point, we are not going to prioritize improving the click flow for enabling pipelines processing as we have already migrated almost all projects to pipelines-processing automatically. We are expecting the migrate the last cohort this week, at which point only a handful of extremely complex projects remaining.
Since such a high percentage of projects are already enabled, I suspect you are seeing that screen because you simply haven’t run any builds since pipelines became enabled. That’s the second option on that empty-state pipelines page you are viewing:
However, this page is a bit outdated now that almost everyone is on pipelines processing, so we’ll take this feedback as a data point to get it updated.
Please let me know if you have further feedback on the new UI!
