Feature Requests

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

It would be great to allow users (depending on permissions) to delete the projects themselves. This is currently not available on the UI and on the API (see https://circleci.com/docs/api/v2/index.html#tag/Project ). See a previous Discuss post here: https://discuss.circleci.com/t/add-ability-to-delete-a-project-from-circleci/936/12 In addition, I wonder if this feature may be something the system offers under privacy.circleci.com .

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

The reason is because we build environments based on the workflow and if its fails we are able to destroy servers build as part of the job , but when someone cancels the job we are not able to do the same and we have to manually destroy the env CCI-I-1285

Filters should allow for tags with branches not one or the other. It seems a pretty common use case to want only a branch to build but not run a deploy workflow unless branch:v1.0 tag has been added/approved/merged etc. CCI-I-305

The new Trigger Pipeline modal is not scrollable so if you add enough parameters, the Cancel and Run Pipeline buttons are not clickable - need to use Tab and Enter keys.

On some projects, we run unit tests, then "fan out" to have deployment steps per environment, each with its own approval step. Currently there is no way to reject; only "approve" or "cancel" (where cancel is a no-op and leaves the job open subject to approval) While this works, and allows us to deploy to multiple environments when desired, it would be nice to be able to reject or disapprove explicitly so that the job does not remain "On Hold". CCI-I-486

We have a different setup for our nightly builds that are triggered by a cron ( https://circleci.com/docs/2.0/workflows/#nightly-example ). If something fails and we want to test it without waiting for next automatic build, we currently have to update the cron, commit, push, revert the cron change, commit, push. It would be nice to have a UI to trigger these builds (Re-running them is not an option since it won't pick up the changes we made to fix the issue). CCI-I-432

Github PRs show if the PR branch has conflicts with the base branch. CircleCI shows test results on the PR branch. What is missing is the ability to see whether test results fail when the PR branch is merged into the base branch. Admittedly, it’s not everyday that PRs break tests of other PRs, but it does happen - for example when there’s a change in UI text: A feature developer issues PR A testing for some specific text in the UI: “The status is FOO”. PR A contains a view test checking for the existence of “The status is FOO”. A another developer issues PR B that implements a product decision to change all uses of “FOO” to “BAR”. Github says branch is clear to merge PR B is merged (Github says there are no conflicts; CircleCI says tests pass) PR A is merged, without problem (Github says there are no conflicts; CircleCI says tests pass) The base branch now has a test which fails because the application produces a view with the text “The status is BAR”, but the test in PR A expects “The status is FOO”. Fail. All of the ways of dealing with this currently seem bad: Constantly merge into the PR branch, making a mess of the commit history Rebase the PR branch onto the base and force push onto Github (a no no for obvious reasons) Catch the test failures later in the base branch (inconsistent with gitflow and other branching strategies) A feature would be nice, but a work around would be great too. Source: https://discuss.circleci.com/t/show-test-results-for-prospective-merge-of-a-github-pr/1662 CCI-I-926

We typically have a workflow with multiple phases (or jobs in circle config), for example, run tests -> deploy to staging -> deploy to production. Occasionally when we have an issue on production we want to redeploy the previously deployed version (rollback), as far as I know, in CircleCI our only option is to re-run a whole workflow from beginning to end. Is it possible to re-run a previously successful job rather than the whole workflow? CCI-I-794