Feature Requests

At the moment, create a new git-branch in Bitbucket is triggering automatic Circle-CI build although no commit have been pushed to this branch yet. This resulting in a redundant build and in-case your pipeline resides on commit-it it might override resources using this commit-it. CCI-I-684

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 .

Originally asked here: https://discuss.circleci.com/t/auto-cancel-builds-on-default-branch/5536 We would like auto-cancel to apply to the default branch, specifically because we have a deploy action associated with it. The deploy is slow and multiple builds are often racing with each other and we occasionally get an older build that finishes after a newer one, leaving us with older code deployed. (This is only for a staging environment deploy in our case though.) CCI-I-214

It would be great to have a metric available in the Insights that shows the time being spent by pipelines being on hold. I think customers will be interested to do analysis on such idle time which potentially could identify slow processes in the delivery pipeline and ultimately give the tools to improve speed

When a project is configured to use OIDC, it should be possible to use these credentials to pull a privates image(s) from GCR when starting the executor. Users currently have to pass in a long-lived service account key (image attached). OIDC can be setup for GCP (1), but private image pulls are not yet supported. (1) https://circleci.com/docs/openid-connect-tokens/#google-cloud-platform

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

Currently the image defined in a container runner's helm chart will be overridden by the image defined in the job's configuration. In some cases it would be helpful to use the image defined the in helm chart, instead of having to a customizable service container.

Hello, would be great if CircleCI could expose Project ID as a pipeline variable. It would help us to improve our OIDC setup.

It would be useful to be able to trigger a job from a workflow based on a git commit message matching a pre defined regex. This could then be used to deploy code to a test server based on a commit message (i.e. "Some useful commit message #test001" would trigger a deploy to test server test001). An example yaml may look something like this: workflows: version: 2 test-and-deploy: jobs: - test - deploy: requires: - test filters: commit: only: - ^.*#((test|dev)([0-9]{3}))$ In the above example, the deploy job would only trigger if the commit message contained a match (i.e. #test001). The commit message (or matched regex) would also need to be made available via an environment variable in order for the job to know which server to deploy to (similar to the way the tag is stored in $CIRCLE_TAG). CCI-I-763

SARIF: https://sarifweb.azurewebsites.net/ Similar to how you expose test results in the UI/API, it would be great to support more generalized static analysis results. SARIF is a common format that can be used across many languages and tools Github supports SARIF format: https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/uploading-a-sarif-file-to-github