Feature Requests

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

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

I added a manual approval "trigger_rollback" job recently to my Circle 2.0 workflow and did not like the UI integration with github. On builds where I did not trigger this optional "trigger_rollback" job, the overall Github status was "Some checks haven't completed yet." (See screenshot.) I talked to CircleCI support and they told me to deselect the status check for a "type: approval" job as described in this github article: https://circleci.com/docs/2.0/workflows-waiting-status/ , which I had already done. I still need the "trigger_rollback" job and corresponding status check. The "trigger_rollback" status check is type:approval, so I want it to be pending but I don't want the overall PR status to be pending -- instead I want the overall PR status to be green and say "All checks have passed." CCI-I-445

We would like to see a feature added to limit the user accounts that can approve an "hold for approval" block. This would allow a release manager or gatekeeper be the only one to release to a production environment. It's best practice and good procedurally to be able to secure deployments to production environments or at least gate them properly.

It would be great if CircleCI allowed you to configure an automatic retry of a build upon failure. Ideally, you would be able to specify the max number of times you would like it to retry. Taken from: https://discuss.circleci.com/t/support-auto-retrying-of-failed-builds/13332/6 CCI-I-935

https://ideas.circleci.com/ideas/CCI-I-664 was (accidentally) merged to an unrelated idea, thus I'm reopening this.Seems like lots of people would like this feature -- see https://discuss.circleci.com/t/job-priority-in-workflows/16893/9 for example. Adding a simple option that would let us make some workflow jobs higher-priority than others could really help us tune our CI setup to finish faster. CCI-I-1372

I'd like my workflow on master branch to run asap - and before any pull request workflows that are in progress. I am currently using AWS CodePipeline to handle my master branch because of the current limitations.(But I guess that would be solved by https://discuss.circleci.com/t/auto-scaling-and-pay-per-use-option/16152/7 ?) CCI-I-291

Sometimes I have a lot of pending jobs but some of them are much more important for me. Currently I can kill the remaining ones but I don't want to kill as they have some importance as well. So it would be great to be able to change the pending jobs priority e.g. with just drag & drop in a jobs list (list of all the jobs for an organization, list for a repo, list for a branch). CCI-I-1081

As described in https://discuss.circleci.com/t/product-update-infrastructure-failure-badge-in-circleci-ui/47282/8 from the customer standpoint it is unclear why the server (especially when reliant on app.circleci.com ) has failed. We've tracked a few of these back to there being issues with memory but there are a few other causes such as using a port in the range of 32768 - 60999 ( https://circleci.com/docs/executor-intro/#port-ranges ) which support suggested may be a problem. As a customer troubleshooting build failures on a system that's been stopped by an outside event it's basic troubleshooting for us to have a reasonable error message to work with.

With increased popularity of lerna / yarn workspaces monorepos, support for things like this seems to be a must: save_cache: key: core-dependencies-{{ checksum "yarn.lock" }} paths: - node_modules - packages/*/node_modules CCI-I-239