Orbs

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

Team, I did reach out to circle ci customer support for configuring slack notification on workflow fail/ pass. But after trying multiple solutions provided by Josh and team, we failed to achieve it. So please provide this feature. Requirement: Slack notification on workflow fail/ pass event Use case: Regression has multiple job setup to execute automation test cases in 5 containers. So once this jobs are completed I would like to receive a notification each job status in one line expected output: workflow master-regression failed Jobs: goals2019 - failed, rtf email_rtf- passed, profile- failed

Is it possible for me to have someone train me in a vigilante misson to catch child molesters useing this platform???can we develop an AI thats in a package to be and under aged girl on Snapchat or similar form I wanna help be a part of cleaning up our local streets and save woman such as my biological sister who was molested as a child if anyone can possibly point me in the right direction I would appreciate that thanks...I am getting a team together to help also but without a program I think it's gonna way less sufficient thanks! for your time Krizmer Rees

When deploying an orb, the default should be Private. This currently defaults to public and requires a --private flag for the orb to then be Public.

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

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

.NET SDK 7 is now in the standard channel, and it would be immensely useful to have it installed in the Windows orb.

Copied from: https://discuss.circleci.com/t/support-for-full-semver-2-0-0-specification/41111 I’d like to publish my orbs such that build metadata is included in the version (i.e. v1.0.0+aef234b.34). This is so that we can quickly work our way back to the commit (via the git short sha) and the build (via the circle ci build number) that produced the published orb. This is very helpful for us during times when we need to debug something. Are there plans to support the full SemVer 2.0 standard as specified here? https://semver.org/#backusnaur-form-grammar-for-valid-semver-versions

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: circleci/path-filtering@0.0.2 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