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.
Status Badges for Private Orbs
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
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: firstname.lastname@example.org 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 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 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.
Support multiple files in .circleci folder
We are migrating to a mono-repo setup for a number of previously separate codebases, and our CircleCI config file has grown to many hundreds of lines. Now that config is within a .circleci/ directory, is there an opportunity to split up the config file into multiple pieces to make it more comprehensible? There was a similar feature request files here previously: https://discuss.circleci.com/t/support-multiple-files-in-circleci-folder/18705 CCI-I-246
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
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 to host orbs in git repo
It would be nice to be able to reuse orbs by simply referencing the git repo and tag.