Feature Requests

We show CPU and RAM usage under the Resrouces tab. We should show ephemeral storage usage as well.

GCP service account keys are often encoded and passed around as json blobs (e.g. the gcloud CLI tool requires this format). Unfortunately secret masking doesn't seem to apply to json blobs, so if the environment is logged somehow these private keys will be printed in full. Here's an example of the format: { "type": "service_account", "project_id": "PROJECT_ID", "private_key_id": "KEY_ID", "private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n", "client_email": "SERVICE_ACCOUNT_EMAIL", "client_id": "CLIENT_ID", "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL" } More documentation here: https://cloud.google.com/iam/docs/keys-create-delete#iam-service-account-keys-create-console Also the default-enabled secret masking is fantastic and handles this automatically for most of our secrets! Thank you for this feature!

In some instances it may be that a user makes multiple commits to a branch in a short amount of time, causing multiple Workflows to execute at the same time, possibly deploying in an incorrect order. "Auto Cancel Redundant Builds" may not be suitable for all situations in which multiple deployments are expected. Solution: Enable a way to ensure that commits to a new branch are queued for sequential execution. CCI-I-840

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.

While CCI allows you to separate builds into steps, it's very common to find that a singular step is multi-phased itself. It would be extremely helpful if, within a build step, the output was timestamped. This is the Jenkins equivalent: https://wiki.jenkins.io/display/JENKINS/Timestamper I'd be most interested in the duration feature, more so that having the timestamps and needing to work out duration of steps myself. CCI-I-360

When tests are run with parallelism, tasks which do not complete for any reason may not upload test results. When "re-run failed tests only" is run CircleCI retrieves the failed tests, and re-runs those. It does not re-run tests that are missing due to a failed task. This can result in successful tests being reported and tests from failing tasks being ignored, and subsequently potentially causes PRs with missing tests to be merged. Implementing logic to check for failed tasks and running those tests along with tests reported to have failed would prevent accidentally merging PRs where tests are missing.

GitHub released Draft PRs https://twitter.com/github/status/1096093162345508864 We have users requesting we add support to not run against branches without a Draft PR, creating this feature request to gauge interest and inform prioritization. It would be nice to have the option to run CI only on PRs which are not draft PRs, as they are intended as work in progress and are likely to be in a broken state which is expected. The option to force trigger a build on such requests with an API call will be nice to so that developers can develop their own integrations like running CI on a comment in such a PR. And CI should be triggered as soon as the PR is marked as ready for review (not a draft anymore). CCI-I-883

We have jobs with manual approvals at the end of our workflow for optional steps (for example, pushing an image to repository, which we only want to run in some cases). Right now, that makes it impossible for us to integrate the single workflow with GitHub status checks, since those are entirely workflow dependent and not job-dependent. For the time being, we've split it out into 2 workflows, but since the same jobs are run in both workflows, this creates a lot of unnecessary job duplication in order to create proper workflow dependencies. Formerly (this doesn't integrate properly with GitHub due to manual approval): Workflow-1: A -> { B, C, D, E } -> (F) -> (G) -> (E) Becomes (with Workflow 1 integrated with GitHub): Workflow-1: A -> { B, C, D, E } Workflow-2: A -> { B, C, D, E } -> (F) -> (G) -> (E) This spawns 5 extra jobs for each code push! There are a few ways we could solve this problem, but none of them are currently supported in CircleCI: 1) Allow GitHub checks to integrate at the job level instead of at the workflow level (we would revert to Workflow-1 with status check depending on {B, C, D, E}) 2) Allow GitHub checks to ignore jobs with type: approval ( https://circleci.com/ideas/?idea=CCI-I-445 ) 3) Allow workflows to trigger other workflows (we would be able to skip A ... E if Workflow-1 triggered Workflow-2) ( https://circleci.com/ideas/?idea=CCI-I-273 ) 4) Allow for cross-workflow job dependencies (similar to (3), with Workflow-1 triggering Workflow-2 and skipping A ... E) CCI-I-1013

Use Case: We have some Jobs in our workflows, eg linting of code. If these fail the whole workflow shows as Failing, forever. Is there any way we can mark certain Jobs as not important? Would be nice if these non-important jobs would show with status= warning and not failed.Similar (but not the same) as: https://circleci.com/ideas/?idea=CCI-I-216 CCI-I-646

Please add this option to run builds manually in a user friendly way. It's ClickOPs I know, but this is what we need to offer to developers sometimes, few clicks and 3 sec later your build is done and we are not a blocker anymore. https://circleci.com/docs/triggers-overview/#run-a-pipeline-from-the-circleci-web-app