OIDC for AWS ECR private image pulls
When a project is configured to use OIDC, it should be possible to use these credentials to pull a private images from ECR  when starting up the executor. Projects with OIDC enabled  currently still require static AWS keys for ECR image pulls.  https://circleci.com/docs/2.0/private-images/#aws-ecr  https://circleci.com/docs/2.0/openid-connect-tokens/
Customizable audience claim in OIDC tokens
A key security aspect of OIDC tokens is that an issuer provide them with audience fields specific to the third-party they will be used to autheniticate with. For example: A token issued to authenticate to AWS should have an audience set to sts.amazonaws.com for example. This ensure that tokens issued to authenticate with one party and not abused to authenticate against a different one should the token be leaked accidentally. It would be awesome if the OIDC tokens now injected into builds in the CIRCLE_OIDC_TOKEN environment variable could have specific audiences set instead of the current Org UUID which provide no additional meaningful information to create policy information against (indeed it is already encoded in the subject).
Additional metadata in context OIDC tokens
It would be nice to have additional metadata, such as branches or workflow names in the context token. Our application for this is we have separate workflows for different packages in a monorepo, and we would like to be able to gate access to different sets of cloud permissions based on the branch or workflow that is being executed.
add_ssh_keys Able to use all SSH Keys
Any SSH keys that you configure for CircleCI, be it a Deploy Key, a User Key, or one or more Additional Keys, will not be automatically added to an executor that you run in a workflow. There are only two ways to have an SSH key be added to an executor: * Use the checkout command. * Use the add_ssh_keys command. ## The checkout command: Using the checkout command will cause either the Deploy or User key to be added depending on which one you have set as the preferred key. ## The add_ssh_keys command: Using the add_ssh_keys command will allow you to add one or more of the Additional Keys configured in your project to the executor that it is invoked upon. You cannot use this to add the Deploy Key or the User Key. ## The problem This creates an interesting challenge in some situations: Given we have a project (Project A), that in its workflow also checks out another project (Project B), we will use an SSH key that allows access to both projects, and add it as the User Key to Project A's CircleCI config. Project A's workflow builds Project B. But the job that builds Project B does not (and should not) run the checkout command. This is because Project A has already been built by an earlier job in the workflow, so using that command would check out a fresh copy of Project A and lose the built environment. So using the checkout command is off the table for grabbing the User Key that we need to use to build Project B. To work around this, I had to add a duplicate of the User Key as an Additional Key, just so I could add it to the executor via the add_ssh_keys command. ## Proposed solution Allow me to reference the fingerprints of both Deploy Keys AND User Keys in addition to Additional Keys when adding keys to a job via the add_ssh_keys command.
Show Parallel Shard on Flaky Test Output
It's almost impossible to find the logs for a flaky or failed test in the tests view when you run with high parallelism.
Support ARM resource class on Docker executor
Some customers that are building for multiple architectures would like the ability to build both AMD and ARM images on Docker executors.
Allow branch whitelist to override “Only build pull requests”
This is mostly copied from a thread in the Community Forum here - https://discuss.circleci.com/t/allow-branch-whitelist-to-override-only-build-pull-requests/6392 The goal is to be able to have Circle automatically build all commits to the default branch as well as other specially named branches without having to build non-PR branches. This is very useful for those of us who have expensive steps in our build process (like tests that run on external servers, or those using the mac OS builds who want to save minutes). Minimum viable here would be to allow a list of branch names. Better would be to allow a list of branch names and/or regexes to specify branches. We have a work-around that we developed locally by opening up fake PRs from our release branches into master as part of our process. But it's manual, error prone, and inelegant. Supporting a whitelist would be much nicer. CCI-I-215
Support new M1 ARM-based Macs
M1 based macs compile software stack 2x as fast (according to customer). More apps & companies are going to start running on M1 too
Trigger pipelines from other pipelines
This allows for more complex orchestration of workflows that span multiple repositories, common for instance when you're building & deploying microservices with inter-dependencies. Currently we need to code our own solution to trigger the next pipeline, watch it, handle error completions and timeouts. There's also no visual feedback either of course and Github checks integrations also needs to be coded in.
Job name remains the same when you run parameterized job more than once within the same workflow
Currently, if you run a parameterized job more than once within the same pipeline ( across different workflows) the job name is auto suffixed. For example build > build-1. We want to be able to have all jobs (with different parameters) persist the same name.