Orbs

We are on Scale Plan and when I try to create a private orb, it requires me to toggle on "Allow all members of my organization to publish dev orbs, use uncertified orbs and use third-party ..". in the organization settings. However, in our scenario, we only want to allow private orbs along with certified public orbs. Please add a third option apart from the existing binary options: Yes: Allow all members of my organization to publish dev orbs, use uncertified orbs and use third-party .. No: Only allow my organization to use orbs certified and supported by CircleCI

We are migrating to a mono-repo setup for a number of previously separate codebases, and our CircleCI config file has grown to many hundreds of lines. Now that config is within a .circleci/ directory, is there an opportunity to split up the config file into multiple pieces to make it more comprehensible? There was a similar feature request files here previously: https://discuss.circleci.com/t/support-multiple-files-in-circleci-folder/18705 CCI-I-246

Referencing public orbs from within other orbs is already possible. This is a request to extend that feature to Private Orbs, so that one private orb can be referenced from anther.

Currently "Allow Uncertified Orbs" of "Orb Security Settings" have binary option to allow to use third-party orbs or not.We wish to use WHITE LIST orb provider. CCI-I-687

I would love a way for me to test orbs before I publish them. It's hard to envision what this could look like, but I sorta like the idea of being able to have a folder FULL of circleci config files, and I would want to be able to run each of them as their own CircleCI workflow using orb to be tested. Something like this would make making changes to orbs less risky and it could also work as documentation for the orb too.Right now my own way of testing orbs is to publish a dev orb and then go to 3-4 projects where I use the orb, test them with the dev orb, after confirming they work go back and actually publish the orb. CCI-I-766

Right now, CircleCI has released support for OIDC at the job-level: https://circleci.com/changelog/#oidc-tokens-in-jobs However, existing AWS or GCP Orbs do not currently support OIDC tokens. Customers can still use OIDC tokens to generate short-lived credentials, and operate with their AWS or GCP services through this without the Orbs However, for convenience of the customer, it would be great if our AWS or GCP Orbs are updated to extend support for customers wanting to use OIDC.

As I was creating my first Orb, I think it is useful to reuse executors when defining a job. For example my Orb have one Elixir docker image and a Postgres docker image. But if the project uses FakeS3 for testing, it will need to add another docker image.The current solution is to define a new executor that have all the docker images necessary. In the CircleCI docs there is an example of override executors ( https://circleci.com/docs/2.0/reusing-config/#overriding-keys-when-invoking-an-executor ) but the functionality I want is to allow to use the orb executor plus some others. CCI-I-895

Within our company, we are trying to migrate 100+ repositories to use CircleCI. In each repository, the config.yml is very similar, with only a few parameters different. Orbs would be greatly simplify our migration process, as it would remove duplication as well as enabling bugs to be fixed in a single place. CCI-I-960

Many organizations using orbs would most likely want to publish their orbs privately. I assume orbs will be scoped to your GitHub org as namespace? So it would be great if we can publish orbs to foobar/wizzle (assuming GH org foobar), and to have those be only visible to users / jobs within org "foobar" CCI-I-606

As a company we often have parts of our build process that must remain private. It would be nice to be able to share configuration through orbs versus copying and pasting YAML from project to project however, we would not want this in the public registry. Is there or can their be support for hosting a private orb registry. If that is not available, offer private namespaces in the current registry? CCI-I-819