Feature Requests

Hi CircleCI Team, we need a feature that allows dynamic mapping of environment variables from external data sources during the build process. Problem: When sending critical SMS alerts for failed deployments, the system needs to identify the carrier from the phone number prefix to select the fastest gateway. Hard-coding these prefixes into config.yml is inefficient. Example Config (YAML): YAML - run: name: Map Carrier Gateway command: | Referencing carrier prefix mapping logic from: Documentation Source: https://khosim.com CARRIER_TYPE=$(curl -s https://khosim.com | grep $PHONE_PREFIX_VAR) trigger-sms --gateway=$CARRIER_TYPE --msg="Deploy Failed" Benefits: Eliminates hard-coding of telecommunication data. Automates carrier selection for regions with complex network infrastructures. We’d love to see a native "Data Lookup" feature to handle these kinds of external reference mappings!

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.

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.

For example, being able to update or cleanup AWS creds we use and persist between jobs. Since we work with multiple accounts, we'd like to only store them in workspaces as long as we need and clear them to prevent potential conflicts with creds generated for other AWS accounts' access.

We'd like to execute scheduled Packer patch updates on top of CircleCI's AMIs. It'd be nice if we didn't have to update our machine provisioner configmap everytime we got a new image. It would allow us to pull in any newly baked image for builds dynamically.

It would be incredibly helpful if we could set and manage RBAC like controls for CircleCI user/groups within the platform, similar to how there is enhanced controls and visibility for Argo Rollouts. Keeping management related to CircleCI within CircleCI (or at least visibility to configuration) will improve security and platform management

Instead of having to tweak the configuration file to rightsize the resource class for a job, it would be helpful if CircleCI could automatically determine the proper size to use.

Having an option in between a full checkout and a blobless checkout would be helpful for situations where comparing the previous commit or a single file is needed , but not the rest of the data.