Feature Requests

Since Dec 2021, the default resource class is set to Large for new projects. For organizations, it would be great to be able to set a default resource class (e.g., medium ) at the project or organization level.

Provide guidance or features to enable efficient use of stacked pull requests without triggering multiple workflows

On the Deploy summary page for a given component, I have bars for each of my environments and little red/green/blue circles representing each deployment. Right now, there is a hover card for failed and successful deployments. The hover card shows who triggered, it, date, version, etc. However, right now the in progress deployments do not have a hover. I believe a hover should be added so the hovers are consistent across all three statuses, and so I can quickly see who is deploying into what environments. Example URL: https://app.circleci.com/deploys/github/my-org/components/1abc1-1abc1

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.

At this time, the Insights API excludes workflows triggered by tag pushes. Adding this feature will allow customers to view workflows, including those triggered by tags via GET /insights/{project-slug}/workflows rather than having to query all pipelines. CCI-I-1413

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.

Would be good to have a button "End SSH session" to avoid us to be waiting 10 minutes to move ahead with the build. This box will stay up for 2h0m0s, or until 10m0s passes without an active SSH session. CCI-I-364

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.