Orbs

Currently, when an orb version is yanked, it also yanks any dependent orb versions. Additionally, when specifying an orb dependency using a major version, the system resolves to the latest version of that orb at the time of publishing. Since there are no built in methods to easily see what versions are going to be affected, this creates potential issues with version management and dependency resolution. This feature request proposes implementing changes to improve orb version management and dependency resolution through any or all of the following enhancements: Change the version resolution to occur at pull-time instead of at publish time 2.Expose the specific versions using CLI/Web UI tooling (one or the other or both). Which would provide clear visibility into which exact versions are being used and allow users to see resolved dependency versions before execution Allow administrators to configure whether resolution happens at pull-time or push-time or even baked at first pull. Allow configuration options such as: Pull-time resolution (always latest) Push-time resolution (current behavior) First-pull caching (resolve once, then cache)

We would like to identify the version of the orb that a job is using, and pass that to our API. I do not see a corresponding env var in the current list . Could we get a new env var to get the version of the orb currently used?

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

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

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

In a single-file orb a developer can define some top-level parameters as yaml anchors and re-use them within different steps/jobs/workflows. This is a very handy tool for keeping the config file DRY. However, this feature does not appear to be supported when using the orb development kit. I propose that anchors should be able to be defined in the @orb.yml alongside other top-level config values. Example @orb.yml: version: 2.1 description: > Example for CircleCI orbs: aws-s3: circleci/aws-s3@2.1 awesome_param: &awesome_param description: >- Set to true if awesome. type: boolean default: true

Status badges are only available for public orbs at the moment. Similar to the API token used for pipeline status badges, can we get this functionality for private orbs

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

If I'm not mistaken, the "Usage" column for private orbs is not valuable in the UI. Since "private" orbs are private to the org, can't be shared to other orgs, and the usage column only indicates the usage in orgs, all private orbs would always show 1? It might make more sense to suggest "N/A", with a tool tip to this affect. Even better, would be data about how many projects in an org are USING a private orb.