Feature Requests

We struggle with slow caching and restoring processes. Better insights into caching efficiency and strategies would help us optimize our build processes.

Please strongly consider moving the cancel workflow element next to the workflow graph element in the preview pipeline details page, elsewhere or having some space for separation. Perhaps adding a confirmation to the cancel. This would go a long way to prevent accident cancels for pipelines and deploys.

Have single agents for simple validation steps, like security reviews, code style reviews etc. Users could invoke them simply by adding them as a step to their job config, e.g. security-review code-review etc For implementation these could be carefully crafted LLM prompts for a start. Users will probably want to toggle whether such a step is blocking (hard fail) or not.

Currently, we utilize holds on our workflows to require a pair of eyes to check on deployments heading to production. While a great feature, it is often unclear when jobs are stuck in a "hold" unless you're glued to the CircleCI console and are acutely aware that a build is being executed on a branch that even needs an approval. It would be very handy to receive notifications for workflows in a "hold" status, as well as to even approve them through Slack! CCI-I-1028

Configure all relevant repositories and packages

In Snowflake, you can setup data shares to allow other organizations to access data in the data warehouse. This allows an easy way to query data inside CircleCI without hammering the API with complicated ETL processes.

Pipelines and their triggers are stored in project settings and not all users, especially new users, will know to look there. The manual trigger UI shows available pipelines, but not their triggers. It would be helpful if this information was displayed in the project's overview or another higher level area.

For Docker Convenience Images, support major version tags, such as cimg/node:15 for the Node.js image.

Would be nice to be able to trigger certain builds or jobs by commenting on a pull request. CCI-I-1213

We'd like to be able to have more granular permissions on who can see projects in an organisation and who can’t. Ideally we would like to prevent certain users from seeing certain projects and pipelines from those projects on the pipelines page.