Feature Requests

Description: Currently, the CircleCI Slack app only supports notifications for the default branch of a project. Teams frequently need visibility across more than one branch — for example, monitoring both main and a release branch, or a set of long-running feature branches. What we'd like: The ability to specify multiple branches (not just the default branch) when configuring Slack notifications at the project level in the CircleCI Slack app. Why it matters: Teams often have more than one branch that matters for operational visibility. Limiting notifications to a single default branch means teams either miss important failures on other key branches, or have to fall back to the Slack Orb with manual YAML configuration — which defeats the purpose of the no-config Slack app integration. Proposed solution: Allow users to enter one or more branch names (or branch patterns) when setting up project-level Slack notifications in the app. This could be a multi-value input field or support for wildcard/regex patterns.

Today, serial-group skips a queued job whenever a newer pipeline in the same project holds or waits for the same group. That's right for deployments, but it breaks serial groups used to protect a shared resource, such as a staging database used by integration tests. In that case every pipeline needs to run, one at a time. Current behavior (from the docs) "Jobs from newer pipelines (higher pipeline numbers) take precedence over jobs from older pipelines within the same project. If a job from an older pipeline tries to run while a newer pipeline's job is waiting or running, the older job is automatically skipped." Problem scenario PR A's pipeline acquires serial-group: org/project/staging-tests and runs. PR B and PR C queue for the same group. A merge to main triggers a pipeline that uses the same group. When PR A finishes, PR B and PR C are skipped (not_run) because main's pipeline is newer, even though they come from unrelated branches. As a result, developers have to re-run skipped PR workflows by hand. These workflows also show as successful even though their tests never ran. Requested change Add an optional setting that controls which newer pipelines can skip an older one, for example: integration-tests: serial-group: key: << pipeline.project.slug >>/staging-tests supersede: branch # project (default, current behavior) | branch | revision | none project: current behavior, for backward compatibility. branch: a newer pipeline skips older queued jobs only on the same branch. Jobs from other branches wait their turn in FIFO order. revision: a newer pipeline skips older queued jobs only for the same commit SHA, for example on re-triggers. none: a strict FIFO queue that never skips. It's still bounded by the existing 5-hour queue timeout. Why native support matters The community eddiewebb/queue orb, which did FIFO queuing, is deprecated in favor of serial-group. It also relies on legacy v1.1 APIs and a personal API token. Workarounds such as polling the API inside the job use credits and hold a runner slot while waiting. Native serial-group queuing waits for free. Auto-cancel redundant workflows already handles "newer push on the same branch". A branch scope would make serial-group work the same way for shared-resource locks. Environment: CircleCI Cloud, GitHub org, self-hosted runners plus cloud executors. Serial groups are used across PR and default-branch pipelines

As things are in flow, even while thinking, getting feedback to the user regarding what is transpiring would provide a much better user experience. I'm using Chunk for the 1st time today and while it's been thinking for 5 minutes now, I have no idea if it's stuck, genuinely doing work or I don't know what.

I'm using a Microsoft Teams for Chat tool, so I want you to add Microsoft Teams for Chatroom Integrations. Could you consider about that? CCI-I-650

We're launching CircleCI functions in beta, a new way to reuse config alongside orbs. Functions are versioned, tested programs that set up the tools your jobs need, like installing Node, configuring AWS, or setting up Docker. You and your coding agent can find, configure, and validate them before a pipeline runs. With functions you can: Use 10 CircleCI-maintained functions for Node, Python, Go, Ruby, Java, .NET, AWS, Docker, browser tools, and the GitHub CLI Catch version and input mistakes before your pipeline runs, with errors that tell you what's wrong Get dependency caching built in, with no separate save and restore steps Getting started With your coding agent: Ask your agent to set up CircleCI with functions. It can use the CircleCI CLI or connect through the CircleCI MCP server to find the right function, configure it, and validate your config before you push. With the CLI: Install the CircleCI CLI (v1.8.0 or later), then run circleci function list to browse the catalog and circleci function add setup-node to add one to your config. In your config: Declare the function in a functions: block at the top of your config, then call it by name in any job. See the example in the docs . Functions are free on every plan, and your orbs remain fully supported. Browse every available function in the functions catalog . This is a beta feature, so we'd love your feedback on what's useful, what's missing, and how we can make it better. Drop your thoughts here!

I can't see our firebase build numbers in the new beta UI

As part of the new CircleCI Slack integration, users need the ability to route different types of notifications from the same project to different Slack channels — for example, sending build notifications to one channel and chunk notifications to another. Problem Statement: The new Slack integration currently supports a single Slack channel per project for notifications. This creates friction in two distinct scenarios: Notification type separation — Teams want different notification categories (builds, chunks, etc.) to go to different channels for better signal-to-noise management. Cross-team pipeline ownership — When Team A owns a pipeline definition but Team B's work triggers failures in it, Team B currently has no way to route those failure notifications to their own channel. The only workaround is to make the pipeline never fail and post to Slack manually — which completely defeats the purpose of automated notifications. Proposed Solution: Within the new Slack integration, allow users to configure multiple Slack channel destinations per project, with the ability to filter/route by notification type (build, chunk, failure, success, etc.) and/or by pipeline definition. User Stories: As a platform engineer, I want build notifications and chunk notifications to go to separate channels so each team stays focused on relevant alerts. As a downstream team, I want pipeline failure notifications routed to my channel even when I don't own the pipeline definition, so I can act on failures that affect my work without relying on the pipeline-owning team.

Today, CircleCI Slack notifications only fire on workflow completed. For teams running long-running or scheduled pipelines, that leaves a lot of gaps in visibility. We'd love to see support for the following notification types: Workflow kickoff — notify when a pipeline starts, so teams know a build is in progress. Especially useful for long-running pipelines where silence can be ambiguous. Upcoming scheduled workflows — notify ahead of a scheduled workflow run as a heads-up that automation is about to trigger. Each of these should be individually toggleable so teams can subscribe to only what's relevant for them. Who this helps: Teams running nightly builds, release pipelines, or any workflow where knowing when something starts or is about to run matters as much as whether it passed or failed.

Currently, jobs, parameters and workflows support (or don't) different booleans and conditionals amongst themselves, requiring users to setup different logic instead of keeping things DRY and copying throughout the config file.

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.