Feature Requests

There is a need to manually interact with environments as part of E2E testing. If CircleCI could provide temporary environments for application verification, users wouldn't need to build and maintain their own verification environments, and could use independent verification environments for each execution pipeline.

Approval Jobs currently only offer [Approve or Cancel] options, which creates constraints for flexible workflow configuration. For example, when deploying requires Approval Jobs for both production and staging environments, Jobs and workflows need to be split accordingly. Ideally, we envision the following: Ability to flexibly approve which Jobs execute next from an Approval Job (e.g., checkboxes) Ability to input parameters when approving an Approval Job to dynamically control the behavior of subsequent Jobs

When using manual triggers or Approval Jobs, there are cases where we need to explain how the pipeline operates. Currently, we create an empty Job and use its Job name to provide necessary explanations, but this has poor readability, increases the config file size, and unnecessarily spins up Jobs.

Customers looking to leverage Chunk who want support for underlying LLM outside anthropic and openAI, specifically Google's Gemini.

Add context name visibility in the CircleCI web UI for dynamic configuration pipelines to improve troubleshooting of permission-related failures. Currently, API provides context data but UI does not. Primary solution would be to display the names of contexts that were resolved/attempted during workflow execution in the CircleCI web UI.

It would be helpful to have list or set parameters for jobs, as currently only boolean, enum, and string types are available.

We would like to wrap multiple consecutive jobs in one serial group. For example, we run automated testing against a deployed ECS container. We don't want to one run to deploy the service while a previous run is in the middle of testing against the deployed service. This causes inconsistent test results as some of the tests could be running against the new instance of the service which could have different behaviour. Current pseudo-config: main-workflow: jobs: - checkout-and-build - test-unit - deploy-service <- serial group 1 - test-end-to-end <- serial group 2 - deploy-prod <- serial group 3 proposed: main-workflow: jobs: - checkout-and-build - test-unit - deploy-service <- serial group 1 - test-end-to-end <- serial group 1 - deploy-prod <- serial group 2

We want to be able to use github apps to centralise circle ci config for some of our deployments so its easy to propagate changes to the pipelines and avoid copy pasting the same pipeline in multiple repo's. However, we also want to restrict access to contexts such as our prod deploy context for this group of services but GitHub app based pipelines don't support this in their current state. The ability to restrict context access via security groups is a vital piece of the puzzle as we don't want ALL members of our GitHub org accessing these contexts

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

Currently, the Steps page shows the output from test runs in color - but the Tests page, which shows all the run's failures - doesn't handle ANSI colors This makes viewing the output of your failed tests harder. Colors are useful UI, they should be supported! The current recommendation is disabling color output for tests: https://support.circleci.com/hc/en-us/articles/360003108933-ANSI-color-codes-appearing-in-test-results - but that makes viewing diffs (and other test output) harder.