Feature Requests

In monorepos where multiple teams share a single CircleCI project, sending all notifications to one shared channel creates noise for everyone. We'd like CircleCI to support routing Slack notifications based on the repository's CODEOWNERS file — so the team that owns the files that changed gets notified, not everyone. How it would work: When a pipeline is triggered by a commit, CircleCI looks at the changed files, resolves ownership via CODEOWNERS, and routes the notification to the mapped team's Slack channel. Why CODEOWNERS? Most teams already maintain a CODEOWNERS file for code review purposes. Reusing it for notification routing means no duplicate configuration to manage. Things we'd want: A way to map CODEOWNERS team names to Slack channel IDs A configurable fallback channel for commits that don't match any CODEOWNERS entry Who this helps: Engineering teams in monorepos who want failure alerts to go directly to the team responsible for the changed code, without manual triage or a noisy shared channel. Who this helps: Engineering teams in monorepos who want failure alerts to go directly to the team responsible, without manual triage or a noisy shared channel.

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, CircleCI Slack notifications are routed to a single channel configured at the project level. For teams working in monorepos — where many services or jobs live within a single project — there's no way to send notifications to the right team's channel based on which job or service actually failed. The ask: Allow customers to define a mapping from job name (or service name) to a Slack channel, so notifications are automatically routed to the appropriate channel for each job. Proposed mechanism : Support a YAML configuration file checked into the repo that maps job names to Slack channel IDs. Teams with monorepos could code-generate this file from their internal service registry, keeping it in sync automatically. For example: notifications: slack: routing: - job: build-payments-service channel: C012ABC - job: build-auth-service channel: C034DEF Alternatively, users can dynamically map job names to Slack channels using an API. Why it matters: Without this, all failure notifications for a large monorepo go to a single shared channel, creating noise for teams that aren't responsible for the failure. This is a meaningful barrier to adoption for engineering orgs with 10+ services in a single repo.

This feature request is to create an allowlist for users to add automated code updating tools and bot users (such as dependabot) to work while utilizing the Prevent unregistered user spend toggle.

Current behaviour The CircleCI pipeline is triggered by GitHub on three events: PR opened/updated, push to default branch, and tag push. To clone the correct frontend branch, we use pipeline.event.github.pull_request.head.ref — this works fine for PR events but is unavailable when a PR is merged (i.e. a push to the default branch), causing the pipeline to fail. What we want Restrict the GitHub trigger to PR events only (PR opened and pushed to an open PR), so the pipeline never starts on a merge to the default branch and the pull_request.head.ref parameter is always available.

My input: Analyze this project's CircleCI pipeline. Identify the biggest bottlenecks in cache usage, test feedback speed, and resource sizing. Summarize the top 3 optimizations you recommend. Chunk AI output: No changes made Chunk completed your request but didn't generate any code changes. This can happen when: You cancelled the workflow The analysis determined no modifications were needed The task was informational rather than code-related More context or clarification would help Chunk take action

Users want git tag details (e.g. v1.2.3) and/or the CircleCI release target-version included in build notification emails. Currently, build notification emails don't surface tag or release version information, making it hard to quickly identify which version of the software a build corresponds to — without clicking through to the CircleCI dashboard. Use case: When a build is triggered by a tagged commit or a release pipeline, the notification email should include the relevant git tag or target-version so recipients can immediately understand context without leaving their inbox. Expected behavior: Build notification emails include a "Tag" or "Version" field when the triggering event is a tagged commit or a release, surfacing either: The git tag (e.g. v2.4.1), or The CircleCI release target-version

Currently no notification is sent to notify of a Scheduled Pipeline failing to trigger. A notification or email should be sent to notify the user/admin that this has occurred so that it can be addressed.

Problem: We have a large monorepo without a package manager, and we rely on path filtering to run the right jobs for the right parts of the codebase. Today, path filtering happens inside the pipeline YAML (via dynamic config and the path-filter orb), which means we end up with a single, long, complex pipeline. Suggested Solution: Allow path filters to be configured at the trigger level in project settings — alongside the existing branch and tag filters — rather than requiring them inside the pipeline YAML. This would let us define multiple triggers, each scoped to a specific directory or set of paths, with each trigger pointing to its own focused pipeline config. For example: services/auth/** → triggers the auth pipeline services/payments/** → triggers the payments pipeline libs/shared/** → triggers a shared-libs validation pipeline

CCI-I-130