We're encountering more use cases where customers want centrally managed configurations that can be called and used. For example, many projects may follow the exact same workflows, and any updates to a process need to be reflected in all projects. Orbs are a step in the right direction, but each project must still manually update the orb version to see new changes - a centralized change does not propagate automatically. Maybe if we added a "latest" tag for orbs? We also don't yet support templatizing workflows in orbs, so we still have to write a lot of config. Related ideas: https://ideas.circleci.com/orbs/p/workflows-in-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

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 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

Currently we can only "Allow Uncertified Orbs" globally for the whole organisation. It would be useful if we could do it on per-project basis. CCI-I-780

Similar to this idea https://ideas.circleci.com/ideas/CCI-I-895 , it would be interesting if we could override or "append" the specific steps of a given orb job. Many orbs are very opinionated about how a project is set up and what tools are in use. This is by and large a good thing in my opinion since I am a huge fan of sane defaults. However, any customization or deviation from the norm prevents you from using an orb and instead re-writing a majority of the logic with minor changes. It would be interesting to be able to make orbs a bit more extensible. CCI-I-1482

There is currently a control to allow or disallow 3rd party orbs. While this is ok, I would like the granularity control to introduce cleared and reviewed Orbs to my repo population to avoid unintentional introductions, vulnerabilities or issues. CCI-I-1161

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

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

An integration with artifactory xray would be enormously useful in running security scans against the build artifacts with these features: Ability to specify which types of artifacts should be scanned and how to locate those artifacts (including file based artifacts and docker containers) Ability to define rules for failing a build based on security settings Nice to have: Automatic promotion from a staging repo (in artifactory) to the production repo for items which have passed Ability to specify additional checks on that promotion process (workflow steps that must pass for the promotion to succeed) Automatic cleanup of the staging repo to help keep costs down in artifactory We're particularly interested in scanning docker containers, jar files (scala and java), and javascript. CCI-I-1063