Allow top-level parameter declarations
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: firstname.lastname@example.org awesome_param: &awesome_param description: >- Set to true if awesome. type: boolean default: true
Allow list-type parameters in Orbs
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
Allow deleting 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.
Allow CircleCI CLI commands to work with private Orbs
At the moment commands like orb source and orb info don't work with private Orbs as they are not available via the public registry. However, these commands are useful for maintaining and developing Orbs so they should be adde for private Orbs as well.
Allow non-Owners to publish Orbs (aka granular permissions for orb publishing)
Could be a project level API key with publishing permissions, or use team membership like contexts do. Some means to expand the population of folks who can deploy prod versions of orbs without giving them global admin rights in GH. CCI-I-1108
Allow only partner and certified orbs
Currently, you can allow uncertified orbs which includes partner orbs. I would like to have the ability to only allow certified orbs and partner orbs but not any other orbs.
Allow to use third-party orbs by white list
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
Workflows in orbs
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
Allow private Orbs to be viewed on Orb Registry
At the moment private Orbs are not appearing on the registry. However, it would be nice if anyone who had access to a private Orb (AKA anyone at the Organization that published it) could view it on the registry. This would likely require some sort of verification of access, maybe even having to log into CircleCI first to verify.
Update Path Filtering Orb to be configurable
Recently I learned of the circleci/path-filtering orb that uses the continuation API in a Setup Workflow. This is a really powerful set of tools, except for some reason the base-revision is not something that can be dynamically controlled. While you can set the base-revision for the path filtering orb to any valid value, including other parameters, it is not possible to dynamically create a value for the base-revision. For example, if the base-revision is set to a value of master it works fine. But if we create a pre-step that gets the base revision from Github, the value cannot be used as the base revision. Relying on the pipeline.git.base-revision as a dynamic revision is not reliable, and doesn't work the way one might hope it would. In practice this means that developers using CircleCI in my project need to manually update the base-revision whenever they are working on a different base from main / master . Can the orb be updated to accept an environment variable exported into $BASH_ENV from a pre-step, or can we have some other mechanism for dynamically controlling this parameter? Ideally I would be able to do something like this version: 2.1 setup: true orbs: path-filtering: email@example.com workflows: generate-config: jobs: - path-filtering/filter: pre-steps: - run: name: Fetch Base Branch from Github command: | BASE_BRANCH=$(curl -X GET \ -H "Authorization: token $GITHUB_TOKEN" \ -H "Accept: application/vnd.github.groot-preview+json" \ -L "https://api.github.com/repos/$CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJECT_REPONAME/commits/$CIRCLE_SHA1/pulls" \ | jq '..base.ref') echo "export BASE_BRANCH=$BASE_BRANCH" >> $BASH_ENV base-revision: $BASE_BRANCH mapping: | path/to/dir/.* build-my-job true Path Filtering orb https://circleci.com/developer/orbs/orb/circleci/path-filtering