I personally feel that separate pipeline view does not make too much sense. If you want to get an overview of all builds ongoing, the builds view will do the job; if you want to check CI/CD overview of commits, the commits page will do the job; and if you want to promote/check stage of particular build, the pipeline view of itself will do the job.

May I know what type of work you are typically do on the GitLab pipeline view?

Well, that might be where the difference of opinion lies. I'm not running 1 CI build pipeline (CI -> Release for example) but instead 25+ 'build' jobs that don't build anything, but test. I have a very CI heavy pipeline, no CD

The reason I created 25+ test jobs is for easier visualization of where the issue lies, easier retry of a single testsuite on failure and easy distribution across multiple hosts. If I put all the tests in one job I need to re-run all the tests on failure and can only run the (very, very heavy testsuite. As in, can easily saturate 32 cores) on a single host.

The downside is, I've been using onedev for a couple days and am at buildnumber 1300+ :)

So if there's a pipeline centric view with an easy retry button (issue #862), I can ignore the soon to be thousands of unrelated builds and pretend the pipeline itself is one large unit.

Here's a screenshot of what I had vs (one of the views I've found) now

Having both one pipeline which has passed or failed and having it all grouped together per stage with an inline retry button on failure was nice :) (onedev runs the pipeline much quicker, which is nicer ;))

Or is there a different way I can group these builds together without losing parallel execution and granular retry?

So I understand that you want to know status of your test jobs, where it fails, and can easily rerun all failed or some failed.

Pipeline view shows all defined jobs, and connect them by defined dependencies. But it may also include unrelated jobs, which may distract your attention. Instead I'd suggest to concentrate on the job status. For instance, I guess you may have an aggregation test job which depends on all other separate test jobs to reflect the final status (and can even retrieve test reports from all separate test jobs and publish them as a whole) . You just care about that aggregation test job. You can create a custom query to only show that aggregation test job in builds page, and can even subscribe to it to get notified upon failure. For failed build of the aggregation job, you just open its pipeline view to see which sub-tests is failed and can selectively re-run them.

Of course, OneDev will also be improved to re-run all failed jobs in the pipeline with a single click as you've suggested in another improvement request.

I like the aggregated test job idea, I'll look into it, thanks.

I've also noticed that now that I've figured out how the 'PR build jobs' work the sidebar works nicely as an overview.

Retry would still be nice though, closing this for now