It would be helpful to have a CLI command like circleci namespace list or circleci info namespace . If the namespace is lost the only way to find it is if an orb or runner was created in it.

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

Currently the following is extracted from an example.yml: Comments Executors not included in the orb Commands not included in the orb Including these in the example on the orb registry page would allow orb users to have a one-stop shop for information on how to use an orb in their config.

Allow the deletion of private orbs so users can stay within their orb limits. Private orbs have a limited scope of users, so if the owner is aware of the risks of breaking internal CI pipelines then they should have the option to delete orbs as necessary.

I want to be able to define an entire workflow in an orb, using the jobs of my orb and allowing parameters to conditionally choose which jobs to run and allow parameterization of branch and tag filters as well. CCI-I-615

Hey all, Is there any means to turn our public orb to private orb please ?

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.

It'd be useful to allow handling lists of values for a parameter, without having to resort to workarounds like parsing comma-separated lists in string types. I think it would be useful to be able to specify something like: steps: - myorb/foo: bar: - baz - qux And have the myorb/foo command called with a bar parameter equal to [ "baz", "qux" ] . CCI-I-701

I have a few workflows where we evaluate a branch for changed paths and do a circleci step halt if there are no hits. This works well enough, but the issue is that in the UI the job containing step is still marked in green (as is the skipped job). Ideally we would have a halt syntax that allowed recording a success, failure, or new (as far as I can tell) "skipped" state for the jobs that didn't run for a particular invocation (e.g. a PR changeset). CCI-I-1496

Orbs are great as reusable components but also considerably tidy up individual components as part of single, complicated build setups. Currently there is a way to do local, "private" orbs "locally" by including the orb configuration under a key in .circleci/config,yml . However this still means we must maintain a giant singular yml file which can grow to thousands of lines potentially with all the workflows etc. A "simple" solution for local orbs would be if circleci read additional .yml files in .circleci/orbs/* for a given project and merged the contents under the orbs key. This effectively means that the yml contents of .circleci/orbs/hello.yml would be equivalent to defining the same content under orbs: hello: This allows circleci build components to be worked on in modular fashion and provides a step between a local orb that is "inline" and one that must be maintained completely externally from the project. CCI-I-704