Feature Requests

While self-service audit capability by an end-user through the UI is a very nice feature, it would be great to allow for dynamic log shipping or making the audit logs queryable through the REST API , so they can be fed into a Security Incident and Event Management type solution. (or into Splunk, another logging tool, etc) As a fall out of the CircleCI Security incident announced in early January 2023 (rotate secrets), having the ability to quickly diagnose this data and compare it to other data we already had from other systems would have made security triage significantly faster/easier.

Share your thoughts on our project administration v2 APIs. https://circleci.com/docs/api/v2/index.html New capabilities supporting webhooks, triggers, and configuration APIs will be available the week of April 8th 2025.

Steps such as Restoring Cache capitalize the first letter of each word in the step name. Some steps, such a Checkout code do not. Some users have requested that we improve the consistency of our step naming conventions. CCI-I-1195

Whenever some tests fail I have to go into the details of the tests job and click on "Rerun failed tests" in the button dropdown at the top right. I would love to have that button right in the pipeline overview when you expand a pipeline to reveal the workflow jobs. It would be amazing if there were a button similar to "Rerun workflow from failed" placed to the right of the job name, so I could rerun the failed tests without having to go into the details of the job.

You are able to see all workflows/jobs for a given branch by going to https://circleci.com/gh/{org}/{project}/tree/{branch} such as https://circleci.com/gh/socialtables/ent-killer/tree/master It would be extremely useful to see a list of all tagged jobs/workflows for all tags. We use tags to trigger staging/production builds and have no way of visualizing a record of all workflows/jobs of this type. Added filtering to be able to get workflows that have done a certain step would also be very useful. For us, viewing all workflows that have succeeded job deploy-production would allow us to fully use Circle to manage deploys. CCI-I-621

Issue: 1. Imagine a pipeline that spins up 3rd party services or containers that would usually be "cleaned" up at the end of a pipeline, but if that pipeline fails, the final clean up job will never be given the chance to run. 2. Currently sending out any kind of notification data to third-party services while running in a pipeline can be difficult, both for the reason already described above, as well as the fact that the results and data for that pipeline will not be available to the API until after the pipeline has run, limiting the amount of information that can be exported. Solution: The ability to specify that a job will execute after the pipeline has run. This should run regardless of how the pipeline ended (or should be configurable). This job should have access to all of the pipeline data for that pipeline (where currently the API does not update until the pipeline has finished). This feature will enable a number of notification, stats, and reporting orbs and greatly improve interactivity with external services utilized within pipelines.Related: https://ideas.circleci.com/ideas/CCI-I-1227 CCI-I-1300

A request to allow internal IP address for SSH commands. They would like to restrict the IP addresses that SSH uses to internal ones only so they don’t need to open random SSH ports

Currently when creating a scheduled pipeline trigger, intended to run once per hour, there is no control as to when the trigger will execute within the hour specified. In extreme cases it can run close enough to the end of the hourly window to cause confusion or delays relative to expectations. Per docs: "Why did my scheduled pipeline run later than expected?" https://circleci.com/docs/scheduled-pipelines/#scheduled-pipeline-run-later Although subsequent runs occur at a consistent time, greater control in specifying that recurring time is desired. Eg) a narrower 30 minute or even 15 minute time range would be desireable

There are links in the pipeline view commit ID back to the GitHub source code that it is building. However, there doesn't seem to be a link back to the GitHub PR. I see that there was one feature request for this previously. But I don't see this feature in the current UI. https://ideas.circleci.com/cloud-feature-requests/p/new-ui-link-commit-message-to-code-in-pipelines-view

It is awesome CircleCI natively implemented queue for jobs. One of the main feature of the eddiewebb/queue orb was ability to skip some jobs conditionally, so if one instance of the job is running, other instances will be skipped completely. Unfortunately, this option is missing in a new feature provided by CircleCI. Use case is next: we have different workflows (let's name them 1, 2, 3, 4) to build and deploy different part of our application. At the end of each workflow end-to-end tests will be triggered (technically it's implemented as a call to run another workflow with tests, let's name it T). When some of workflows running simultaneously, they will call tests several times in a short period of time. Obviously that in this case we only need single test execution, not all of them. My suggestion is to add a 'add-to-queue' parameter to a 'serial-group' key add-to-queue: type: enum enum: ["all", "none", "latest"] default: all description: "Parameter that defines if new instances of the job should be added to the queue all - when job (1) is running, and job (2) and (3) and (4) triggered - in this case all new instances of the job (2) and (3) and (4) will be added to the queue none - when job (1) is running, and job (2) and (3) and (4) triggered - in this case no new instances of the job will be added to the queue, all jobs (2) and (3) and (4) will be cancelled latest - when job (1) is running, and job (2) and (3) and (4) triggered - in this case only the latest instance (4) will be added to the queue, and all other instances between (1) and (4) will be cancelled. In case job (1) is still running and instance (5) triggered, it will be added to the queue and instance (4) will be cancelled"