Feature Requests

Having the option for a confirmation page (maybe optional as another button next to "run pipeline") that shows only the things we have set that are not-default, or maybe grouped or color coded so that we can see what is non-default and what all the values are would help to avoid making mistakes in trigger modals that are really long and have to be scrolled through.

Customer has a merge queue enabled in their GitHub repository, which means that they do not run tests on the default branch. Tests that would otherwise run on the default branch instead run on branches prefixed with gh-readonly-queue/, which means that they have no way to check which tests are preventing PRs from actually merged. An important note in their setup is that they do not block merges on tests that flake on PRs, but they do block in the merge queue. The merge queue is the only gate to merging. In other words, they still want to see flaky test insights on PR branches but also want to see flaky test insights on any branch prefixed with gh-readonly-queue/.

> WHAT: Trend-based automatic resource class scaling (opt-in) < The ability for CircleCI to automatically scale a job up to the next resource class based on that job's historical usage trends. If a specific CI job shows memory or CPU usage trending upward over time — i.e., consistently maxing out its current resource class — CircleCI would auto-bump it to the next class up without requiring a manual config change. > WHY: < As usage scales — steadily increasing volume, new services and projects added over time — teams want jobs to right-size themselves automatically, avoiding the manual overhead of monitoring and adjusting resource classes as workloads grow.

Letting orgs customize or provide an alias to stock GH App triggers will ease adoption for orgs that having long standing labels embedded in their system. For example, an org may use a Github webhook to trigger a CircleCI build with the ci: run-ci label, configured under a machine user. They would like to ensure that the underlying Github user working on a PR (that could apply label and trigger a build) would be associated as the author of the new pipeline. GH App adoption would solve for this BUT would require the entire org to update their label from ci: run-ci to run-ci for it to work. An easier path to adoption would get orgs to take advantage of new features and functionality.

Ran into the limitation where job groups can't reference other job groups within. Would be nice if this were possible so that de-duplicating jobs could be done more granularly to make pipeline config files more readable.

Currently, if you want to require all concurrent jobs run as the result of a matrix job, you have to list every single one of them out. It'd be much better if there was a built in wildcard capability that allowed you to pin to the config job name rather than having to pin to each unique job name. Otherwise, a wildcard capability for requires could work too. But the first option feels better.

We have a merge queue enabled in our GitHub repository, which means that we do not run tests on the default branch. Tests that would otherwise run on the default branch instead run on branches prefixed with gh-readonly-queue/ , which means that we have no way to check which tests are preventing PRs from actually merged. An important note in our setup is that we do not block merges on tests that flake on PRs, but we do block in the merge queue. The merge queue is the only gate to merging. In other words, we still want to see flaky test insights on PR branches but we also want to see flaky test insights on any branch prefixed with gh-readonly-queue/ .

Allow users to filter build notifications to specific workflow names in the new Slack integration. Today, all workflows in a project trigger notifications with no way to scope by workflow name — teams with multiple workflows (e.g., a nightly regression, a deploy pipeline, and a PR lint check) get notified on all of them equally. Requested behavior: Users can specify which workflow names should trigger Slack build notifications Configurable per project in the Slack notification settings UI Use case: Teams running diverse workflows across many repos need to target notifications to the workflows that matter (e.g., only notify on a "deploy" or "regression" workflow), especially for repos where not all workflows map to a deploy event and the Deployments notification category doesn't apply.

When I change a filter, such as "My Pipelines" or the project I'm on, it resets the other filters. This is very disorienting.

Environment variables are important to get correct. When you enter one in the UI, it's all password-masked. Since you can't view the full value once it's saved, the only way to confirm the value is correct is to trigger a build.At the very least, there should be one of those "eye" toggles that's so hot nowadays that allows you to temporarily unmask the field. CCI-I-1155