Feature Requests

Customers want the ability to connect to both Github Enterprise Server (on-prem) and Github.com when using CircleCI Cloud

Description: This is a request for a native way to send CircleCI pipeline data directly to OTel endpoints — formatted according to the official OTel CICD and VCS Semantic Conventions — without needing a custom intermediary script. Current Workaround: Users need to maintain a script that reads CircleCI environment variables and manually generates OTel-formatted traces before forwarding them to our observability endpoint. This adds maintenance overhead and is fragile. Desired Behavior: CircleCI natively populates a structured OTel attribute object from pipeline run data and sends it to a user-configured OTel endpoint. For example: { ' cicd.pipeline.run.id ': <pipeline_run_id>, 'cicd.pipeline.result': <pipeline_result>, ... } Ideally this object would be mutable so teams can add or override attributes before export. Use Case / Impact: This would benefit any team using OTel-native observability tools (Honeycomb, Datadog, Grafana, etc.) and eliminate the need for custom trace-generation scripts on top of CircleCI webhooks.

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 lines created by jobs in a workflow can not easily be followed to show visually how they are linked to other jobs. See screenshot below.Feedback from user:`` Our engineers are having a hard time understanding the workflow and the path that it takes to reach the deployment stage. The jobs appear to all be linked a lot of the time but they are not. Unless you dive into the yml or know the workflow by heart it can be quite confusing. Is there a better way to configure our workflows or is there a fix that needs to be done?This ticket includes a secure attachment. Use this link to access the attached files: https://circleci.sendsafely.com/receive/?thread=B4XS-UDRE&packageCode=nGkzVUW0d28570CmzUhq1eIqyWtpZFYA30YBcuBTGdk#keyCode=GWvIOHXTlUvPQ6jQUQ2hBb6QMv-450XSUY1ZT5_PetA `` CCI-I-850

I have a test suite that, unfortunately, has a number of tests that occasionally fail. Our test suite takes about 20 minutes to run. It's really frustrating to have to rerun the entire test suite when we have one or a few false failures. It would be really nice if there were somehow and option to rerun failing tests. CCI-I-211

Currently, any merges to master trigger all steps of all workflows. In an monorepo that houses multiple projects, this results in multiple redundant steps as, for example, the backend is re-tested and re-deployed even if only frontend changes have been made. It is currently possible to do: workflows: flow: jobs: - deploy: filters: branches: only: - master It would be useful for all teams that run a monorepo to also be able to specify, say: workflows: flow: jobs: - terraform: filters: modified_paths: only: - /^infrastructure/ - deploy: requires: terraform filters: modified_paths: only: - /^app/ CCI-I-208

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

When testing new pipelines, it is often necessary to delete a pipeline to prevent further pipeline triggers while tweaking the config. That pipeline then needs to be re-created to continue testing. Being able to temporarily disable a pipeline would be reduce some of the toil when setting up new pipelines.

When using the "Run Pipeline" feature, the name of the parameter is currently left blank, and open to incorrect use. It would be useful to pre-populate this with a list of parameters that have been defined within the config file.

It would be nice to have additional metadata, such as branches or workflow names in the context token. Our application for this is we have separate workflows for different packages in a monorepo, and we would like to be able to gate access to different sets of cloud permissions based on the branch or workflow that is being executed.