Extend Executors with images
We've started using custom orbs, these define a base image, say cimg/clojure:<tag>. We'd like to also offer executors with common tools, Localstack, MinIO, Redis, Postgres, etc. However there's no way of adding additional images to an executor currently. I'd suggest one of two solutions: Allow executors to have more images provided via parameters. Right now it isn't possible to have a when block in the executor config, or extend the executors Extend executor image config when specifying it, rather than replacing it. This would be a breaking change so it would likely need to be under a separate executor parameter, rather than docker Right now we're creating two executors, one with just the main runner for the core language, and another with Localstack and Minio, which is our common setup. If we ever need more docker images, we need to copy and paste that config from the orb for all the images.
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.
Apply "when: always" to orb commands.
https://circleci.com/docs/2.0/configuration-reference/#the-when-attribute While the when attribute can be attached to individual commands, it can not be directly attached to orb commands. The orb would require an additional parameter which would then need to be passed down into each sub-command of that orb command.example: run: name: Upload CodeCov.io Data command: bash <(curl -s https://codecov.io/bash ) -F unittests when: always # Uploads code coverage results, pass or fail namespace/orb: when: always # This is not a valid parameter CCI-I-1360
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
Allow Private Orbs along with Certified Public 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
Allow Sharing Of Private Orbs Across Separate Orgs
As a user who has projects spread across multiple organizations, it would be helpful if an org could be allowed to use a private orb from another org.
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
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 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