Feature Requests

In some instances it may be that a user makes multiple commits to a branch in a short amount of time, causing multiple Workflows to execute at the same time, possibly deploying in an incorrect order. "Auto Cancel Redundant Builds" may not be suitable for all situations in which multiple deployments are expected. Solution: Enable a way to ensure that commits to a new branch are queued for sequential execution. CCI-I-840

We use contexts actively, there are workflows where we have 10+ jobs requiring the same context, it would be great if we could just specify it once for a whole workflow.

As per https://github.com/circleci/circleci-docs/issues/2040#issuecomment-368139737 It would be nice for users to have a way to shallow clone. Currently, we do checkout to checkout. It would be nice to be able to pass a depth into that like shallowClone:10 and then use the number 10 as the depth for the clone. The PR linked has a modified version of the existing script that works. CCI-I-254

At the moment, the workflow steps are displayed horizontally. But our workflow is very flat and there's lots of steps. Would it not make more sense to display the workflow from top to bottom (vertical)? Or at least a toggle in the view on how to display it? CCI-I-535

There are situations where you would always want a workflow to run, even if a newer build has started. The current implementation of the "auto-cancel redundant builds" feature is all or nothing and doesn't allow granular control of which builds should be canceled. It would be great if the feature allowed for specifying workflows that it would ignore.

Currently contexts are set per job . I would like to set context on workflow . Based on https://discuss.circleci.com/t/how-can-i-reduce-redundancy-when-using-contexts/37935/2 , did not find existing idea here.

Now that we have OpenID Connect we can use federated workload identity in GCP. This works great for jobs, but prevents us removing the last key for pulling docker images from GCR as a executor. It would be nice just to be able to configure the docker executor to work with OpenID Connect so that we can remove the last service account key

GitHub released Draft PRs https://twitter.com/github/status/1096093162345508864 We have users requesting we add support to not run against branches without a Draft PR, creating this feature request to gauge interest and inform prioritization. It would be nice to have the option to run CI only on PRs which are not draft PRs, as they are intended as work in progress and are likely to be in a broken state which is expected. The option to force trigger a build on such requests with an API call will be nice to so that developers can develop their own integrations like running CI on a comment in such a PR. And CI should be triggered as soon as the PR is marked as ready for review (not a draft anymore). CCI-I-883

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

In some cases environment variables are useful to print out, it would be helpful to be able to whitelist the ones we'd like to show. CCI-I-1223