Feature Requests

CircleCI already provides helpful floating tags like lts, but there isn’t a clean way to pin to a specific major Node version while still automatically receiving patch updates. If I want to stay on Node 22 and make a conscious decision about when to upgrade to Node 24, I currently have to specify a full minor version (e.g. 22.21), which then requires manual updates for every patch release. It would be very helpful to support major-version-only tags such as cimg/node:22, which would always resolve to the latest available patch within that major release. This would allow teams to intentionally control major upgrades while still benefiting from automatic security and bug fix updates. This approach would reduce maintenance overhead, improve security hygiene, and align with common Docker image tagging patterns.

Would be nice to be able to trigger certain builds or jobs by commenting on a pull request. CCI-I-1213

For our workflow, there are other branches in addition to the default branch that we would like to disable auto-cancel redundant builds for. CCI-I-1584

The workflow-completed and job-completed webhook event types only report information following a terminal state. Users wanting to track duration live (sub-entities like started_at, created_at and triggered_at) are unable to do so, and must wait until their workflow or job finishes. Would it be possible to allow limited sub-entities (listed above) for a new workflow-triggered event type?

Noticed a need for a more efficient and flexible way to manage and delete artifacts, particularly those that have already surpassed their expiration date. This functionality would enable users to manage their artifacts more effectively, remove unnecessary files as and when needed, without solely waiting until the expiration date.

For CI optimization at the step level it is difficult to see metric trends. If a job's metrics change then a manual, step level investigation needs to be done on many job instances to make an assumption of the root cause. This trial and error optimization could be mitigated with access to data on the step level.

Support for improved security posture and opportunities to more securely automate API interactions that require highly privileged creds (i.e. publish orbs, policy sets). Additionally, job-based API keys to improve security. Currently v2 automation requires long-lived service account credentials that need to be rotated.

IaC support for GH App pipeline definitions would be great, in additions to the existing API or manual management.

Specifically, a native capability to call a pipeline in another project and wait for a response in the upstream project without custom orchestration steps, workarounds with approval jobs, and/or consuming credits

Optimize costly pipelines with smarter build triggers. The path-filtering-orb is error prone and fragile. Would introduce some degree of parity with Gitlab's downstream pipelines and would be useful in ML training workloads.