Feature Requests

Adding the ability to run restore_cache on a step failure would allow for saving time on potentially expensive post-failure actions. This could help with cleanup steps or aggregation steps.

Currently, you passing parameters to IP ranges is not supported. The following syntax is supported : circleci_ip_ranges: true This feature is in request of supporting the following syntax: circleci_ip_ranges: << parameters.true_or_false >>

Now that we have OpenID Connect we can use federated workload identity in GCP. This works great for jobs, but prevents us removing the last key for pulling docker images from GCR as a executor. It would be nice just to be able to configure the docker executor to work with OpenID Connect so that we can remove the last service account key

It costs time and mental energy to enter the test job first, scroll up and then click the "Rerun" dropdown.

We are having problems getting all projects under an organization since we are using API v2. API v1 allowed us to obtain this information by requesting the organization's projects or getting info from "/me". With API v2, this is not possible, and we cannot find a way to get all projects of our organization to operate with them. How can we solve this issue? It would be helpful to have a "/projects" query to obtain this information.

In project settings you can add triggers to run jobs periodically. Thos are great but they are a pain in the *** to use. Once you create around 10 of them, it becomes impossible to visually find the one you need to modify / delete. Being able to sort and filter them out based on name but also parameters or other attributes would be a relief !

Currently, when rerunning a job that is itself a rerun with SSH enabled, both rerun options will kick off an SSH rerun. This can be confusing and at the least the UI should be modified to make more clear what these buttons do. For example, removing the redundant "Rerun with SSH" button and clarifying that a normal rerun will use SSH would resolve a lot of confusion.

Bug report can't access8

On our master branch we have a pipeline that we want to test each commit, but because of external resources used as part of the integration test suite we can only run one job at a time. This means we have to have a merge master who is only merging one job, waiting for it to finish and then merging another job. It would be great to be able to set the parallelism allowed on that branch to 1 WITHOUT having to turn off Kill Redundant Builds, which we want on PR branches. Similarly, we have branches for deployment to various environments based on merge to a branch. Killing a redundant build there can screw up the deployment, so a release manager has to merge to that branch and then wait for it to finish. As a last step on that job we push a commit to the release branch with the version, which triggers a new build, which creates a race condition for killing the redundant build. We are happy to have it spin up another job and we can cancel that build based on the author of the commit, but not being able to limit parallelism and prevent killing redundant means we cannot push the version commit when we make it we have to do it as the VERY last step and hope the deploy job doesn't get killed by redundant.

As a software engineer I want to run end to end tests for each change So I can quickly identify breaking changes Example scenario There are 5 repos to build, for services 1-5. Services 1, 2, 3 and 4 have a large number of inter-service tests; service 5 is standalone. Upon building code for service 1, 2, 3 or 4 in Circle CI, the build enters a step that deploys the build to an integration test environment (ITE), and triggers the full suite of tests. If more than pull request for Service 1, 2, 3 or 4 triggers this step at a similar time, the deploy to ITE is FIFO queued pending a successful outcome for the currently running integration tests. Upon building the code for service 5, the build and deploy waits for any other Service 5 builds to pass tests, and then it deploys and runs the tests. If Service 1, 2, 3 or 4 fails tests, their queue is paused until the problem is fixed (a successful rerun of that branch's tests) and then the builds continue. If Service 5 fails its tests, its queue is paused until the problem is fixed (a successful rerun of that branch's tests) and then any other Service 5 builds continue. Notes Ideally builds should be able to run independently to a point (so unit tests can run and Docker images can build) but then should enter a sequencing queue. Builds with interdependent repos could be gathered into Build Groups for easy configuration of sequencing. CCI-I-1056