Previously, getting CircleCI notifications into Slack meant configuring the Slack orb yourself — wiring up tokens, managing secrets, and maintaining that setup per project. It worked, but it was a lot of ceremony for something that should just be a setting.

Now, there’s a native Slack integration built directly into CircleCI.

What’s new: Install the CircleCI Slack app once at the org level, then connect individual projects to the Slack channels of your choice. Workflow notifications — including failures, errors, and unauthorized runs on your default branch — start flowing automatically.

Why it matters: No config changes. No orb version pinning. No secrets to rotate. Just connect and go.

How it works: Go to Org Settings > Slack Integration to install the app, then configure per-project notifications from Project Settings > Slack Notifications.

Read the docs · Share feedback

Inconclusive Deployments: Better Visibility and Control These improvements apply to projects using the CircleCI release agent. When a progressive delivery analysis run returns an inconclusive result, your deployment no longer silently stalls. We’ve shipped a set of improvements that give you clearer status, timely notifications, and automatic resolution.

What’s new:

• Inconclusive status in the UI — the Releases page now displays a dedicated Inconclusive badge with clear guidance to promote or cancel, instead of an ambiguous unknown state
• Email and Slack notifications — when a release becomes inconclusive, the person who triggered it is notified with a reason and direct action links to promote or cancel
• Auto-cancel after timeout — releases stuck in Inconclusive are automatically canceled after a configurable timeout, so stalled releases don’t accumulate
• Configurable timeout in org settings — set a custom inconclusive release timeout per org under Settings > Releases
• Email CTAs with deep links — “Promote All” and “Cancel Release” buttons in notification emails now link directly to the action on the release detail page

Gen2 x86 Docker resource classes are now generally available on CircleCI. Based on realistic workload benchmarking, we found gen2 to be 1.4x faster than gen1 equivalents.

Gen2 x86 Docker resource classes are available for users on paid plans in the following configurations:

Not supported:

• Free plans - gen2 Docker resource classes require a paid plan
• Arm-based Docker jobs
• Remote Docker with small.gen2 - the smallest available size for remote Docker is medium.gen2
• IP Ranges
• CircleCI Server

See the x86 (gen2) Docker documentation and CircleCI price list for details.

We’re making Chunk sidecars and Chunk microbuilds available as a Preview for Performance and Scale customers.

Chunk sidecars are fast reproducible cloud based environments for coding agents to validate changes. Chunk sidecars can be customized for your repository and turned into reusable snapshots with all dependencies pre-installed and cached. Just install the skill and ask your agent to create a Chunk sidecar.

With a Chunk sidecar your coding agents can run microbuilds - consistent pre-configured validation checks without having to push code and monitor CI pipelines. Feedback from a microbuild is sent directly into the context window, where the agent can iterate until the validation checks passes. Agent hooks allow you to continuously prompt your agent to keep working until the build passes.

Install the chunk-cli to get started.

You can now sync your CircleCI deployments to Linear Releases by adding a single step to any deploy job. Now, you can:

1. Add the circleci/linear-release orb to your pipeline
2. Have every deployment automatically create a release in Linear with the issues that shipped
3. See exactly which Linear issues went out with each deploy, directly in Linear

What’s new:

• New circleci/linear-release orb available in the CircleCI Orb Registry
• Add linear-release/sync as a step in any deploy job — no shell scripting required
• Works with continuous and scheduled Linear release pipelines
• Compatible with all CircleCI executors

Get started

We’re excited to announce that Smarter Testing is now available in beta for all Cloud customers. This includes test impact analysis, dynamic test splitting, and automatic rerun of failed tests — all designed to help you run fewer tests, run them faster, and get signal sooner, while maintaining full confidence.

What beta means

Beta means the product is in early stages and you may encounter bugs, unexpected behaviour, or incomplete features. When the feature is made generally available, there will be a cost associated with access and usage.

To learn more or share your feedback, please refer to our Discuss post.

Until now, serial groups could only serialize one job at a time — there was no built-in way to keep other pipelines from slipping in between a set of jobs that needed to run together. Many teams worked around this using the Queue Orb, which repeatedly polls the CircleCI API and burns credits while waiting.

Now you can define job groups — a named set of jobs that run as one unit. When serialized with serial-group, no other pipeline can start the same serial group until all jobs in it finish.

Job groups are defined under a new top-level job-groups key. You can use them with or without serial-group — without it, they’re just a way to organize and reuse a set of jobs.

Note: Rerunning any job in a serial group reruns the entire group — including “Rerun job with SSH,” which will enable SSH for all jobs in the group, not just the one you selected.

See our documentation for details.

Chunk tasks can now route outbound traffic through CircleCI’s known static IP addresses.

Enable IP Ranges in Chunk Tasks toggle in Organization Settings → Chunk to get started. Available on Performance and Scale plans.

Learn more in the documentation

CircleCI Cloud now supports GitHub Enterprise Server as an add-on VCS integration. If your organization uses a self-hosted GitHub instance, you can now connect it to CircleCI Cloud and get the same CI/CD experience available to GitHub Cloud users, without needing to run CircleCI Server.

This integration supports most existing GitHub App functionality for GitHub Cloud, including triggering from a wide range of GitHub events (push, pull request, PR comment), as well as custom webhooks, scheduled pipelines, and API triggers.

This feature is currently in Preview. Access is provided on request and involves hands-on support from the CircleCI team. Some features are not yet available during Preview, including self-serve onboarding, GitHub Checks, Chunk, and Rollbacks. Documentation can be shared on request. To learn more or request access, contact your account team.

OpenTelemetry Support for CI/CD

CircleCI now exports pipeline telemetry data to your observability platform via OpenTelemetry. Once configured, CircleCI will emit trace spans for every completed pipeline, workflow, job, and status — giving you full visibility into your CI/CD performance alongside your application traces.

Spans include rich context such as job status, workflow names, VCS metadata (branch, commit SHA, pull request), and direct links back to the CircleCI UI. Span attributes follow OpenTelemetry semantic conventions where possible, with CircleCI-specific attributes (com.circleci.*) for additional detail.

To get started, configure an exporter via the Organization Settings API (see below). CircleCI supports any OTLP-compatible backend — including Honeycomb, Datadog, and Grafana.

View the full OpenTelemetry reference →

Manage Organization Settings via API

You can now manage your organization’s OpenTelemetry exporter configuration programmatically. Three new endpoints are available under /api/v2/otel/exporters:

• GET /api/v2/otel/exporters?org_id=… — List configured exporters for an org
• POST /api/v2/otel/exporters — Add a new exporter configuration
• DELETE /api/v2/otel/exporters/:id — Remove an exporter configuration

All endpoints require the manage-org permission. This enables teams to automate observability setup as part of onboarding workflows or infrastructure-as-code pipelines.

View the full API reference →

NOTE: Managing exporter configuration via the Organization Settings UI is coming soon.

You can now see exactly where your code is and how it got there, directly from the Deploys page.

Previously, tracking a deployment’s journey across environments meant piecing together context from multiple places. Now, the deployment timeline view shows each environment your code has touched in order, with status clearly indicated for each step.

You can:

1. Filter by a followed project on the main Deploys timeline to see the timeline view there

1. Drill into any component or deployment for a detailed timeline view

1. Hover over any deployment to trace its full promotion path across environments

What’s new:

• A deployment timeline view showing the promotion path across environments
• Accessible from the main Deploys page (filter by a followed project) and from any component
• Hover over any deployment to trace its promotion path
• Clear status indicators at each step, green for success and red for failure, and a purple arrow for rollbacks

You can now define reusable deployment progressions for your environments and enforce them across your org, projects, or components.

Previously, there was no built-in way to standardize the order in which code moves through environments. Teams had to manage promotion paths manually, with no guardrails to ensure deployments followed the right sequence.

Now, you can:

1. Create named hierarchy templates (e.g., Development → Staging → Production) in your org settings under Deploys.

1. Set an environment hierarchy as the org-wide default, and assign hierarchies to specific projects or components.

1. Once assigned, version promotions follow that path automatically, and you can see each environment’s deployment status at a glance on the version promotion page.

What’s changed:

• Create and manage environment hierarchy templates from org settings under Deploys
• Set a hierarchy as the org default or assign it at the project or component level
• Version promotion pages now show each environment in the hierarchy with its current deployment status and version

Teams deploying across multiple environments can now standardize promotion paths, reduce manual coordination, and quickly see where any version currently stands across all environments.

It is now possible to configure pipelines to be triggered specifically when a push to a merge queue occurs.

When a pull request enters GitHub’s merge queue, GitHub creates a temporary branch prefixed with gh-readonly-queue/ that combines the PR’s changes with the latest base branch and any PRs ahead of it in the queue. This is the final validation before code lands on your base branch - and it often calls for a different CI strategy than what you run during code review.

With this trigger, teams using GitHub’s built-in merge queue can run a dedicated workflow at the merge gate - for example, a more comprehensive integration or end-to-end test suite - without slowing down the PR feedback loop. It also makes it straightforward to report a required status check on gh-readonly-queue/* branches, which GitHub needs in order to proceed with the merge.

This trigger option is available to all organizations using GitHub, as long as they have installed the CircleCI GitHub App integration. Access it by adding a new GitHub trigger to a GitHub App pipeline from the Project Settings > Project Setup page.

For more information and a full list of GitHub trigger event options, visit the Docs page.

Gen2 Linux VM / (x86) Remote Docker resource classes are now generally available on CircleCI, with CPUs that are up to 180% faster for your multi-threaded Linux workloads.

With over 96% of CircleCI machine jobs being multi-threaded, virtually all Linux VM / (x86) Remote Docker customers can leverage this significant performance boost to accelerate builds and reduce pipeline times.

Gen2 Linux VM / (x86) Remote Docker resources are available for all users in the following configurations:

See the Linux VM (gen2) documentation and CircleCI price list for details.

Today, if an upstream job is blocked and never runs, any downstream job depending on it is stuck — there’s no clean way to say “run this job once everything upstream is done, regardless of the outcome.” This leads to orphaned resources or messy config duplications when trying to implement a workaround.

We’re introducing two new job statuses that downstream jobs can depend on to solve this:

not_run — you can now explicitly condition downstream jobs on not_run, allowing cleanup and fallback jobs to fire whenever an upstream job did not execute.

terminal — an aggregate status that resolves to true when a job has reached any final state: success, failed, canceled, or not_run. Instead of enumerating every possible outcome, you can simply require a job to be terminal.

Here is an example:

workflows:
  test:
    jobs:
      - set-up-test-database   
      - run-tests:
          requires:
            - set-up-test-database
      - delete-test-database:
          requires:
            - run-tests: terminal  # Runs regardless of outcome

Now, delete-test-database always runs once “run-tests” job have reached a terminal state — whether it succeeded, failed, were canceled, or never ran at all.

For more details, visit the documentation.

You can now compare two versions directly from the deploy timeline to see the list of commits between them. Previously, understanding what changed between two deployed versions meant manually tracking down diffs in GitHub, with no easy way to see the commit history from within your deploy view. Now, clicking the compare button next to any release opens a modal with the full list of commits between that version and the currently live one, along with links to view the diff on GitHub.

What’s changed:

• A new compare button on the deploy timeline lets you select any two versions and view the commits between them in a modal, without leaving your deploy view.

Why it matters:

• Whether you’re investigating an incident or reviewing a release, you can now quickly see exactly what changed between versions, right from the timeline. Links to GitHub are included for teams who want to dig deeper into the full diff.

Availability:

Update: AI-generated diff summary now available

• The AI-generated summary of the diff is now live. When comparing two versions, you’ll see a plain-language summary of what changed between them alongside the full commit list.

Availability: Enabled for all users with the global AI feature flag turned on.

It is now possible to configure pipelines to be triggered only when a non-draft pull request is opened.

Combine this trigger option with “Pushes to open non-draft PRs” to ensure pipelines run when changes happen on pull requests that are ready for review.

This trigger option is available to all organizations using GitHub, as long as they have installed the CircleCI GitHub App integration. Access it by adding a new GitHub trigger to a GitHub App pipeline.

For more information and a full list of GitHub trigger event options, visit the Docs page.

A new “successful rerun” view is now visible in the Tests tab on your job page. This view displays tests that were successful after certain number of auto-reruns of failing tests.

Note: Auto-rerun of failing tests is a feature of Smarter Testing.

Sign up for early access to try Smarter Testing during our preview period.

Immediately stop all new pipelines and workflow reruns during incidents, at the organization or project level. In-progress workflows are not affected.

Available in Organization Settings > Advanced and Project Settings > Advanced.

Note: For server customers, this feature will be available in Server 4.10+.

You can now configure deploy markers across multiple projects in a single step, replacing the old project-by-project workflow.

Previously, adding deploy markers meant going through each project individually, which became increasingly tedious as your project count grew.

Now, our new multi-project setup lets you select the projects you want and apply deploy marker configuration to all of them at once. The tool ensures consistent setup across your projects so you can start tracking deployments everywhere without the manual overhead.

What’s changed:

• Deploy markers can now be added to multiple projects simultaneously from a single workflow, replacing the previous project-by-project setup.

Why it matters:

• Teams with large numbers of projects no longer need to spend time on repetitive configuration. Deploy marker setup now scales with you, whether you have a handful of projects or hundreds, so you can focus on shipping rather than configuring.

Getting started:

• Head to your organization’s project settings to try the new multi-project deploy marker setup. To learn more about how deploy markers work, visit our documentation.

Gen2 Linux VM / (x86) Remote Docker resource classes are now available in Beta on CircleCI, delivering priority access to CPUs that are up to 180% faster for your Linux multi-threaded workloads.

With over 96% of CircleCI machine jobs being multi-threaded, virtually all Linux VM / (x86) Remote Docker customers can leverage this significant performance boost to accelerate builds and reduce pipeline times.

Gen2 Linux VM / (x86) Remote Docker is available for all users in the following configurations:

See the Linux VM (gen2) documentation and CircleCI price list for details.

Beta Release Notes:

• This feature is stable but still being refined based on customer feedback
• Preview pricing shown above may change at General Availability
• SLOs are measured but not guaranteed during Beta
• Self-service activation is available now through your config

Scale plan customers can now set and track budget limits for CI credit usage.

Features:

• Organization and project-level budgets: Set weekly credit limits at the org level or for individual projects
• Real-time tracking: Monitor consumption as a percentage of your budget limit
• Automated notifications: Receive alerts when reaching 70%+ of budget limits via email, in-app banners, and build notification warnings
• Comprehensive coverage: Budgets track compute, Docker Layer Caching, storage, IP ranges, and network usage

Access: Org Admins can create and manage budgets from the Plans page. All users with Plans page access can view budget status.

Budgets run weekly (Monday 00:00 UTC - Sunday 23:59:59 UTC) and reset automatically.

You can now promote artifacts using deploy pipelines across environments to ensure the code you tested in staging is exactly what goes to production.

Why we built this: Rebuilding your code for each environment creates uncertainty. Is the code in production exactly what you tested in staging? When something breaks, was it a code change or an environment difference? Teams need confidence that what passed validation is exactly what’s being deployed.

How it works:

• Your CI pipeline publishes a versioned artifact (Docker image, JAR, binary) once. After that artifact passes validation in staging, you can promote that exact same artifact to production, other regions, or any environment without rebuilding.

When you’re ready to promote:

• Navigate to the Deploys page and select the artifact version you want to promote
• Choose your target environment from the dropdown
• The same verified artifact moves across your deployment pipeline

This means no more rebuilding for each environment, no more wondering if staging and prod are running identical code, and faster deployments when rolling out to multiple regions.

A new “Test Overview” widget is now visible in the Tests tab on your job page. When test results are uploaded, you’ll now see:

• Total number of tests run
• Test results breakdown (passed, failed, skipped by the test runner or Smarter Testing)
• Time saved from skipping tests with Smarter Testing

Want to reduce your test execution time? Sign up for early access to try Smarter Testing during our preview period.

The Xcode 26.2.0 image is now available to be used in CircleCI pipelines on the M4 Pro resource classes.

Please see the full manifest for information about the software included with this image release.

Known issues:

• iOS 26 simulators sporadically freeze during boot and may fail to start. We recommend pre-booting simulators and, if they don’t start within 60 seconds, terminate them and restart them.
• Device IDs are inconsistently changing across VMs in Xcode 26. This is an OS-level issue that can affect builds relying on consistent device identifiers. We’ve opened a support ticket with Apple and encourage affected users to do the same to help prioritize a fix.

Server 4.9.0 Changelog

Before Upgrading

See the CircleCI server 4.9 release notes and upgrade guide for this release.

NOTE: Vault is being deprecated and will no longer be supported in server 5.0. Refer to our script for steps to migrate to Tink.

What’s New in Release 4.9.0

The v4.9 release introduces serial groups for job serialization, automatic retries for workflows and steps, and improved caching with Zstd compression. In addition, MongoDB 4.4 or higher is required before upgrading to v4.9.

NEW FEATURES

• Serial Groups: A native mechanism for serializing job execution across workflows. Jobs can now be configured to run sequentially using the serial-group key, preventing race conditions in deployments and other concurrent operations. For more information, see the docs.

• Automatic Workflow Reruns: Workflows can now be configured to automatically rerun on failure using the max_auto_reruns configuration key. For more information, see the changelog.

• Automatic Step Retries: Individual steps within jobs can now be configured to automatically retry on failure. For more information, see the changelog.

• Faster Checkout with Blobless Method: The checkout step now supports a method option that enables blobless checkout for faster repository cloning. For more information, see the changelog.

• Zstd Cache Compression: Cache compression now uses Zstd by default, providing faster compression and decompression with better compression ratios. For more information, see the changelog.

• Job-level Cache Retention Controls: Cache retention can now be configured at the job level, allowing more granular control over cache lifecycle. For more information, see the changelog.

• OIDC Token Reliability Improvements: Enhanced retry handling for OIDC token generation, improving reliability in environments with transient network issues. For more information, see the changelog.

• Configurable Max Run Time: Build jobs now support a configurable maximum run time through the builds_service.custom_max_run_time Helm value, allowing operators to override the default 5-hour limit.

• Dark Mode: Users can now enable “Dark mode” through the CircleCI web app, see the changelog.

CHANGES

• Some CircleCI job statuses that were previously marked as skipped were changed to failed, see the changelog.
• Reduced time to start jobs for very large and complex workflows, see the changelog.
• Personal Access Token (PAT) management has been migrated to the authentication-service. PATs are automatically migrated during the upgrade process. This changes requires that the mongoDB instance used by your CircleCI server is at least MongoDB 4.4. You will need to upgrade your mongoDB instance before upgrading to server 4.9.0. Please reference our MongoDB Upgrade instructions if your mongoDB instance is not externalized.
• Context APIs are now served by the CIAM gateway for improved performance and scalability.
• Redis has been updated to the version 6.2.20 to address CVE-2025-49844.
• The feature-flags service has been removed as it is not required for Server installations.
• Deleting contexts double confirmation now asks for the name of the context, see the changelog.
• Branches now displayed in branch picker regardless of trigger settings, see the the changelog.
• Workflow start time & duration are now copyable from CircleCI web app, see the changelog.
• URL Addressable Orbs - Removes the barriers to reusable config by allowing any file in your VCS to become a CircleCI orb. Allowlist rules maintain security and compliance, see the documentation.

BUG FIXES

• Fixed incorrect trigger event display for scheduled workflows. For more information, see the changelog.
• Fixed an issue where pipelines showed errors when all workflows are filtered out. For more information, see the changelog.
• Fixed branch filter dropdown functionality. For more information, see the changelog.
• Fixed project count on “User homepage”, see the changelog.

NEW SERVICES

New services introduced with this release:

• lock-job-provider - Provides job serialization capabilities for serial groups feature (includes internalapi and consumer components)
• no-op-job-provider - Handles no-operation job types used by serial groups

SERVICE CHANGES

• feature-flags - The feature flags service has been removed as it is not utilized by execution services in Server.

DATABASE MIGRATIONS

The following databases will run migrations when upgrading to this version:

• authentication-service
• insights-service
• lock-job-provider
• no-op-job-provider
• oidc-tasks-service
• permissions-service
• runner-admin

KNOWN ISSUES

Using a custom signed certificate will result in an x509 error for Docker, Machine, and Runner jobs. A fix will be provided shortly in the future.

MongoDB 4.4 is the default database image shipped with CircleCI Server 4.9.1 and above. However, MongoDB 4.4 has reached end of life and is no longer receiving security patches or updates from MongoDB, Inc. Please use our mongo 7 upgrade script to upgrade the mongoDB in your CircleCI Server instance to 7.0. If you have mongoDB 3.6 deployed in your cluster, you will first need to upgrade to mongoDB 4.4 using our mongo 4 upgrade script, before upgrading to mongoDB 7.0.

To learn more about Server 4.9 installation, migration, or operations please review our documentation.

We’ve launched a new email notifications experience that gives you more control over your inbox. You can now opt into a “My Work” filter to receive email alerts only for builds you personally triggered.

Getting Started: Enable the “My Work” filter in your notification settings to reduce notification noise and stay focused on your own work.

Learn More:

• Read the documentation
• Share your feedback to help us improve this feature

You can now convert plain English descriptions into cron syntax when setting up GitHub App schedule triggers. Type a description like “every weekday at 9am” or “twice daily” and get the corresponding cron expression automatically generated. You can review and edit the generated syntax before saving.

Some examples:

The Xcode 26.2 Beta 2 image is now available to be used in CircleCI pipelines on the M4 Pro resource classes.

Please see the full manifest for information about the software included with this image release.

Known issues:

• iOS 26 simulators sporadically freeze during boot and may fail to start. We recommend pre-booting simulators and, if they don’t start within 60 seconds, terminate them and restart them.
• Metal Toolchain is currently non-functional. A workaround is available by running the following commands before use:

    xcodebuild -downloadComponent metalToolchain -exportPath /tmp/MetalExport/
    sed -i '' -e 's/17C5038g/17A5241e/g' /tmp/MetalExport/MetalToolchain-17C5038g.exportedBundle/ExportMetadata.plist
    xcodebuild -importComponent metalToolchain -importPath /tmp/MetalExport/MetalToolchain-17C5038g.exportedBundle

• Device IDs are inconsistently changing across VMs in Xcode 26. This is an OS-level issue that can affect builds relying on consistent device identifiers. We’ve opened a support ticket with Apple and encourage affected users to do the same to help prioritize a fix.

The Xcode 26.1.1 image is now available to be used in CircleCI pipelines on the M4 Pro resource classes.

Please see the full manifest for information about the software included with this image release.

Known issues:

• OS 26 simulators sporadically freeze during boot and may fail to start. We recommend pre-booting simulators and, if they don’t start within 60 seconds, terminate them and restart them.
• Metal Toolchain is currently non-functional. A workaround is available by running the following commands before use:

    xcodebuild -downloadComponent metalToolchain -exportPath /tmp/MetalExport/
    sed -i '' -e 's/17A5295f/17A5241e/g' /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle/ExportMetadata.plist
    xcodebuild -importComponent metalToolchain -importPath /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle

• Device IDs are inconsistently changing across VMs in Xcode 26. This is an OS-level issue that can affect builds relying on consistent device identifiers. We’ve opened a support ticket with Apple and encourage affected users to do the same to help prioritize a fix.

It is now possible to configure pipelines to be triggered by commenting run-ci on a GitHub pull request.

This gives teams more control over when pipelines run - for example allow re-running pipelines without pushing new commits, or triggering builds for draft PRs and work-in-progress branches.

This trigger option is available to all organizations using GitHub, as long as they have installed the CircleCI GitHub App integration. Access it by adding a new GitHub trigger to a GitHub App pipeline.

Support for custom comment keywords is on the roadmap.

For more information and a full list of GitHub trigger event options, visit the Docs page.

The Xcode 26.1 image is now available to be used in CircleCI pipelines on the M4 Pro resource classes.

Please see the full manifest for information about the software included with this image release.

Known issues:

• OS 26 simulators sporadically freeze during boot and may fail to start. We recommend pre-booting simulators and, if they don’t start within 60 seconds, terminate them and restart them.
• Metal Toolchain is currently non-functional. A workaround is available by running the following commands before use:

    xcodebuild -downloadComponent metalToolchain -exportPath /tmp/MetalExport/
    sed -i '' -e 's/17A5295f/17A5241e/g' /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle/ExportMetadata.plist
    xcodebuild -importComponent metalToolchain -importPath /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle

• Device IDs are inconsistently changing across VMs in Xcode 26. This is an OS-level issue that can affect builds relying on consistent device identifiers. We’ve opened a support ticket with Apple and encourage affected users to do the same to help prioritize a fix.

The Xcode 26.1 RC (Release Candidate) image is now available to be used in CircleCI pipelines on the M4 Pro resource classes.

Please see the full manifest for information about the software included with this image release.

Known issues:

• OS 26 simulators sporadically freeze during boot and may fail to start. We recommend pre-booting simulators and, if they don’t start within 60 seconds, terminate them and restart them.
• Metal Toolchain is currently non-functional. A workaround is available by running the following commands before use:

    xcodebuild -downloadComponent metalToolchain -exportPath /tmp/MetalExport/
    sed -i '' -e 's/17A5295f/17A5241e/g' /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle/ExportMetadata.plist
    xcodebuild -importComponent metalToolchain -importPath /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle

• Device IDs are inconsistently changing across VMs in Xcode 26. This is an OS-level issue that can affect builds relying on consistent device identifiers. We’ve opened a support ticket with Apple and encourage affected users to do the same to help prioritize a fix.

The Xcode 26.1 Beta 3 image is now available to be used in CircleCI pipelines on the M4 Pro resource classes.

Please see the full manifest for information about the software included with this image release.

Known issues:

• OS 26 simulators sporadically freeze during boot and may fail to start. We recommend pre-booting simulators and, if they don’t start within 60 seconds, terminate them and restart them.
• Metal Toolchain is currently non-functional. A workaround is available by running the following commands before use:

    xcodebuild -downloadComponent metalToolchain -exportPath /tmp/MetalExport/
    sed -i '' -e 's/17A5295f/17A5241e/g' /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle/ExportMetadata.plist
    xcodebuild -importComponent metalToolchain -importPath /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle

• Device IDs are inconsistently changing across VMs in Xcode 26. This is an OS-level issue that can affect builds relying on consistent device identifiers. We’ve opened a support ticket with Apple and encourage affected users to do the same to help prioritize a fix.

The Xcode 26.1 Beta 2 image is now available to be used in CircleCI pipelines on the M4 Pro resource classes.

Please see the full manifest for information about the software included with this image release.

Known Issues:

• OS 26 simulators sporadically freeze during boot and may fail to start. We recommend pre-booting simulators and, if they don’t start within 60 seconds, terminate them and restart them.
• Metal Toolchain is currently non-functional. A workaround is available by running the following commands before use:

    xcodebuild -downloadComponent metalToolchain -exportPath /tmp/MetalExport/
    sed -i '' -e 's/17A5295f/17A5241e/g' /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle/ExportMetadata.plist
    xcodebuild -importComponent metalToolchain -importPath /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle

• Device IDs are inconsistently changing across VMs in Xcode 26. This is an OS-level issue that can affect builds relying on consistent device identifiers. We’ve opened a support ticket with Apple and encourage affected users to do the same to help prioritize a fix.

We’ve added a new banner that surfaces all your failed deployments across environments in one place so you can catch issues faster and get back to shipping.

Why we built this:

Failed deployments can be easy to miss, especially when managing multiple environments. You need a quick way to see what’s broken at a glance, without hunting through pipelines or workflows.

How it works: When you have failed deployments, you’ll see a banner at the top of your Deploys page with:

• A summary of all failures across your environments
• Namespace and version details when you hover over a specific deployment
• Direct links to the full error details by clicking the arrow on the right

This means less time tracking down what went wrong, and more time fixing it.

Starting November 3rd, CircleCI will begin to gradually roll out a faster checkout method (blobless) as the default checkout method.

Most builds will continue working without changes with blobless checkout. However, you need to take action if your builds require access to historical file contents. For example, tools like Sonar (SonarQube, SonarCloud), Sentry, some coverage or security scanning tools, and custom scripts that rely on git blame, git diff, or git config commands may require full checkout.

To opt into blobless checkout immediately, or to test compatibility, edit your CircleCI YML config to use the “blobless” method.

steps:
  - checkout:
      method: blobless

If your CircleCI job fails, or you prefer to keep the current checkout behavior, edit your config to use the “full” method.

steps:
  - checkout:
      method: full

If you do nothing and your builds break after November 3rd, you will be able to fix them by editing your config to use the “full” method.

Schedule triggers are now available for GitHub App pipelines. This feature allows teams to automatically run pipelines on a time-based schedule, with frequencies ranging from once every 5 minutes to less frequent intervals. Schedule triggers support configuring the actor associated with trigger pipelines, and passing custom parameters.

Getting started

Create GitHub App schedule triggers from the Project settings > Project setup page.

Availability

This functionality is available to all organizations that integrate with GitHub, regardless of whether they also use the GitHub OAuth integration (URLs may include /github/ or /circleci/). To learn more about using the GitHub App integration alongside GitHub OAuth, see the dedicated Docs page.

Notes

• GitHub App pipelines triggered via schedule trigger are never skipped nor auto-cancelled.
• Please note that, as specified in the documentation, a delay of up to 10 minutes may be applied to the configured time. Subsequent runs will maintain the same timing as the initial run.

Current limitations

Schedule triggers for GitHub App pipelines cannot yet be created or managed via API.

What’s next

GitHub App schedule triggers currently use a dropdown interface for frequency selection. We’re planning to transition to cron syntax for more flexible scheduling options. For questions or concerns about this plan, reach out to benedetta@circleci.com.

For more information about schedule triggers, see our documentation.