Feature Requests

Currently the "Remove All" button is at the bottom of the parameters section, meaning you have to scroll all the way down in order to click it. As as user, this creates frustration and I'd prefer having the ability to click it from anywhere in the pipeline triggering page, so it's right beside the "Cancel" and "Run Pipeline" bottom section buttons. Attaching a mock. Thanks! Asaf Ifergan, Wiz Product Team

I'd rather have the option to suppress specific errors like almost all other linters. But I would settle for just being able to disable Circle CI config linting. I have sooo many errors that are not errors, and sometimes I have warnings that I don't care about. As an OCD type person, this is quite distracting. That, or at least fix your errors, like detecting contexts. It's totally broken for us.

Sometimes a particular resource_class type may be temporarily unavailable for various reasons. In such cases, it would be useful if customers could specify a prioritized list of preferred resource classes or tags. CircleCI could then automatically select the first available option from that list to run the job. This provides flexibility across a variety of scenarios and helps customers plan for outages or capacity shortages without building complex fallback logic or maintaining multiple backup workflows. Example: resource_class: xxx resource_tags: [linux, my-own-runner-x86, macos] In this example, if both linux and my-own-runner-x86 are unavailable, CircleCI could fall back to macos to ensure the job still runs without timing out or failing.

Problem to solve: With private orbs, the --org-id argument is mandatory for multiple circleci cli commands, most annoyingly the validate one. Being able to configure a default value in the ~/.circleci/cli.yml config file would be most helpful in this scenario.

I'm using the VS Code extension, but I presume it's the language server (?) that would be responsible for this. I want to be able to add some kind of ignore next line/current line to suppress warnings and (possibly) errors, so it doesn't continue to report problems that I've address/am intentionally leaving.

Problem Statement: No-op jobs and other non-build job types (like approval and release jobs) prepend the workflow name to the GitHub status check name (e.g., workflow_name/job_name), while regular build jobs display without the workflow prefix (e.g., job_name). This inconsistency creates challenges when: Migrating existing jobs to no-op jobs, as GitHub required status checks must be updated Managing branch protection rules across different job types Maintaining consistent naming conventions across workflows Requested Enhancement: Provide an option to control the naming convention for no-op jobs in GitHub status checks, allowing users to choose between: Current behavior: workflow_name/job_name Consistent behavior: job_name (matching regular build jobs)

In Github its possible to have many CI config files in one repo, i want this feature for accounts that are using Bitbucket as well

The documentation allows the use of expression-based job filters, however the circleci-yaml-language-server does not, which causes the visual studio circleci plugin to mark the pipelines as red in the IDE. There is an open issue in the public GH repo about this: https://github.com/CircleCI-Public/circleci-yaml-language-server/issues/335

This utility makes interacting with GitHub extremely simple and would be just as handy to have at the ready and the other base tools like wget, etc. Even though, it's VCS specific, I think its a basic necessity to provide for those that use GitHub.

CircleCI can now trigger pipelines where the config source is different to the checkout source, however this is not enabled when continuing a pipeline. Allow the endpoint to pull a config from the defined config source, and not the checkout source.