Feature Requests

Like most engineers, I prefer to use a dark UI. CCI-I-930

Please add this option to run builds manually in a user friendly way. It's ClickOPs I know, but this is what we need to offer to developers sometimes, few clicks and 3 sec later your build is done and we are not a blocker anymore. https://circleci.com/docs/triggers-overview/#run-a-pipeline-from-the-circleci-web-app

We have parallelism set to 28 to run our tests. If a single parallel run fails, we currently have to rerun the entire job. It would be great to just re-run the parallel run that failed. CCI-I-1329

We should be able to filter by the author of a pipeline.

The recent UI changes to trigger a pipeline and various parts of the app look nicer, but are much less functional. When triggering a pipeline, I used to be able to just click the button, type in my parameter and click run. Now I need to open the dialog, scroll down to the parameter section. Click the add parameter button, and then type things in. The Config source box is getting way too much space. It's entirely useless to me since it was context I selected on the screen before clicking run pipeline. The pipeline input box is also not useful to me. I don't have alternative options when clicking there and I don't even know what they would be. The input parameters are the most important part, and should be at the top Before the screen started with 1 parameter row, now it starts with 0. Starting with 1 is better since 1 param is a very common use case and you can just treat it as 0 if I leave it blank. Everything is stacked vertically here, even for elements that are not very wide. I'm not using this on mobile, so my screen is wide and not tall, so this leaves me needing to scroll to get to the bottom of this dialog, which is annoying. This layout would make sense on mobile perhaps, but for the predominant non-mobile use case, a layout that uses more horizontal arranging of things would be much better.

While self-service audit capability by an end-user through the UI is a very nice feature, it would be great to allow for dynamic log shipping or making the audit logs queryable through the REST API , so they can be fed into a Security Incident and Event Management type solution. (or into Splunk, another logging tool, etc) As a fall out of the CircleCI Security incident announced in early January 2023 (rotate secrets), having the ability to quickly diagnose this data and compare it to other data we already had from other systems would have made security triage significantly faster/easier.

When setting the filter branches on the insights page this should extent to the flaky tests below. Currently, all flaky tests are shown regardless of the filtered branch. Showing only flaky tests from the filtered branched is not configurable currently. This makes it hard to differentiate between real/persistent flaky tests vs failed tests introduced by a momentary mistake. A flag to see it to all branches would be ok, but it can cause confusion when looking for flaky tests on a specific branch.

In order to analyze time-dependent flacky tests, it would be great to have a way to see all failure history with datetimes. In this way it would be possible to download and analyze at what time they fail most often and especially whether this test is flacky through a long period or it just started to fail this time. As an example, I pushed some critical changes and run into a test which failed after my changes. There is no link to previous failures. Insights do not provide any information. Without history I don't know it's me or it is some random stuff. After digging through the code, turned out the bug reproduces with a very small time frame and it's probability is tiny. Would I have the history for this bug, most likely I would found out, that rarely, time to time it failed before. But right now, I can only guess.

It would be great to see the history of all the runs of a specific rspec test. This way, when something fails - we can see how often it failed in the past week or so, and decide if there's a chance it's flaky... CCI-I-341

When adding a new project through CircleCI, a read-only deploy key is automatically configured for the project to allow CircleCI to immediately start checking out code and building our projects.We would like this option extended so that CircleCI can automatically manage projects that may need read-write privileges by default; for example, a build workflow might have some logic to automatically apply git tags to the current branch after a build.Without this capability, we are stuck manually adding user keys to every repository that needs this. It may work for a few repos, but if you need to manage dozens or even hundreds of repos with this capability, you can see how this can get unwieldy. CCI-I-1416