Feature Requests

Bitbucket cloud recently introduced Draft pull requests and also exposes this information in the REST API and Webhooks, see https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-2441 . It would be very useful to have the option to skip building any draft PR's until they are marked as ready.

Currently, when a CircleCI workflow with multiple parallel jobs is canceled, the system sends N+1 webhooks (where N is the number of parallel jobs). This creates integration challenges and unnecessary webhook traffic. We propose to optimize this behavior to align with industry standards and improve customer experience. Current Behavior When a workflow is canceled, CircleCI immediately sends an initial webhook with stopped_at = created_at (indicating 0ns duration) Subsequently, one additional webhook is sent for each parallel job that was canceled Each webhook contains an incrementally updated workflow duration Example: For a workflow with 3 parallel jobs, 4 webhooks are sent with durations of 0ns → 35.4s → 40.1s → 1m 8s Requested Feature Reduce the number of webhooks sent when canceling a workflow with parallel jobs. Send only one webhook when all jobs have been canceled with the final duration User Impact This change would: Simplify integration with CircleCI webhooks Reduce server-side processing for customers with stateless architectures Eliminate the need for custom deduplication logic Align CircleCI's behavior with industry standards (GitHub Actions, GitLab, Buildkite, Azure Pipelines, AWS CodePipeline) Business Value Improve developer experience when integrating with CircleCI Reduce unnecessary webhook traffic and associated costs

CircleCI has a couple of steps that run before user-defined steps within jobs (i.e "Spin Up Environment", "Preparing Environment Variables"). We'd like to be able to similarly define our own steps which can run on our host before the job steps are executed (but after the environment variables and job information are prepared/known). The rationale is to run custom logic to validate environment variables or contents of steps or gate the run based on the committer, etc.

Issue: 1. Imagine a pipeline that spins up 3rd party services or containers that would usually be "cleaned" up at the end of a pipeline, but if that pipeline fails, the final clean up job will never be given the chance to run. 2. Currently sending out any kind of notification data to third-party services while running in a pipeline can be difficult, both for the reason already described above, as well as the fact that the results and data for that pipeline will not be available to the API until after the pipeline has run, limiting the amount of information that can be exported. Solution: The ability to specify that a job will execute after the pipeline has run. This should run regardless of how the pipeline ended (or should be configurable). This job should have access to all of the pipeline data for that pipeline (where currently the API does not update until the pipeline has finished). This feature will enable a number of notification, stats, and reporting orbs and greatly improve interactivity with external services utilized within pipelines.Related: https://ideas.circleci.com/ideas/CCI-I-1227 CCI-I-1300

In CircleCI a branch is only visible in the branch filter once a pipeline has been created on that branch. Under some circumstances it is helpful for CircleCI to be aware of branches without a pipeline so a pipeline can be manually triggered.

Adding a link to the most recent deploy in github would be extremely helpful. I have CircleCI setup with a deploy step for PRs to now.sh , but no way of seeing the deployments URL within Github. CCI-I-416

Summary Add the ability to view all branches in CircleCI for manual build triggering, regardless of PR status, without automatically triggering builds on every commit. Current Behavior Currently, CircleCI provides only two suboptimal options: Non-PR builds ON: All commits to all branches automatically trigger builds, consuming unnecessary build credits. Non-PR builds OFF: Branches without PRs are not visible in CircleCI, forcing teams to create placeholder PRs just to access branches for manual builds. Requested Solution Implement a third option that allows: All branches to be visible in CircleCI's UI regardless of PR status The ability to manually trigger builds on any visible branch No automatic build triggering for non-PR branches Use Case Our workflow involves: Creating frequent WIP branches for development Occasionally needing to build specific branches for internal testing Wanting to conserve build credits by only running builds when necessary Avoiding PR clutter in our repository Business Impact This feature would: Reduce unnecessary resource consumption and build credits Eliminate workflow inefficiencies and repository clutter Improve developer productivity by removing the need for workarounds Provide greater flexibility in our CI/CD pipeline management Proposed Implementation A simple implementation could involve: A new project setting: "Show all branches for manual builds without auto-triggering" Branch listing that includes all branches regardless of PR status Clear UI indication of which branches have automatic builds enabled This change would significantly improve our team's workflow while maintaining the existing functionality for users who prefer the current behavior.

Currently, when a user hits their concurrency limits there is no error message. They will see their builds queueing. The user can use the CircleCI v3 API to get unclaimed tasks for a given resource class( https://circleci.com/docs/runner-api/#get-api-v3-tasks ) to confirm that they have unclaimed tasks. At this time, user rely on CircleCI Support team to share a list of jobs that need to be cancelled. This feature request is for better error messaging when concurrency limits are hit and for exposure to which jobs need to be cancelled in order to move forward.

We’d like to see real-time concurrency usage directly in the UI. Right now, there’s no way to monitor active jobs, queue lengths, or how close we are to our concurrency limit—until we hit it. A live view showing current usage, limits, and queue times would help us better manage workflows and plan for scaling. This visibility is key for deciding when to optimize or upgrade, rather than reacting after delays occur.

In our organizations, we actively use parallels, especially during tests, and try to dynamically manage them depending on the priority of the pipelines. On the "Setting/Plan" page, we have information available that according to our plan, there is a limit of 80 cuncurrent jobs. And I'll tell you, from my feelings, we often reach this limit. It would be great if you could design a page that would contain statistical information for the entire account, with some minimal historical data of 1-3 months. Which would show threshold and actual usage in the form of a graph. Best regards, Leonid Prytuliak DevOps Engineer at Ablefy GmbH