A change to status checks was originally scheduled for April 28, 2025. The scope of the change has been revised based on user feedback.

What is changing?

We are updating some CircleCI job statuses to better align with how we report terminal job states to VCS status checks.

Starting June 2, 2025 jobs that are currently marked as skipped will be changed to failed in CircleCI in the following situations:

• Project is abusive
• User is sanctioned
• SSH key is missing
• Server license is expired
• Parallelism limit is exceeded

Note: Status checks will not be impacted, as these jobs are already reported as failures to GitHub.

Why are we making this change?

In these cases, the failed status more accurately reflects that the job was not successful due to blocking conditions—not because of optional skips or conditional logic. This change also improves consistency across job reporting as these jobs already appear as failures in GitHub.

This is a modification of the plans announced in April for Skipped Status Will Now Return Success which will remain paused.

When will this take effect?

June 2, 2025

Three new tools are available in the CircleCI MCP Server:

We added the get_latest_pipeline_status tool to retrieve information about the status of the latest pipeline on a branch.

We also added two tools to support prompt iteration workflows:

• create_prompt_template will generate an optimized prompt for a user defined task. This is useful for crafting prompts for AI applications
• recommend_prompt_template_tests will generate test cases for a prompt, this makes it faster to try out prompts with a variety of inputs

Download the MCP Server here

Project administration APIs are now available to cloud customers. Perfect for customers wanting to ease new project onboarding, maintain standards across projects, or manage projects with infrastructure as code (IaC practices). For more information see the official documentation.

APIs Available:

• Project
• Pipeline Definitions (Github App)
• Triggers (Github App)

Over the next few weeks we will be following up on the API release with an official Terraform module supported by CircleCI. You will also see more detailed tutorials on how to leverage the APIs and Terraform on the CircleCI blog.

Two new tools made available in the CircleCI MCP Server:

• We added the config_helper tool to assist with CircleCI configuration tasks such as providing support for validating .circleci/config.yml files, recommending fixes, and suggesting best practice improvements.
• We added the find_flaky_tests tool to identify and analyze flaky tests in CircleCI projects, supporting both project URL and local git repository context.

Download the MCP Server here

We’ve recently rolled out the CircleCI Model Context Protocol (MCP) Server. This enables developers using tools (Claude Code, Cursor, Windsurf, etc.) that support the MCP protocol to interact with CircleCI.

Agents and AI tools can now fulfill developer requests, such as “Find the latest failed pipeline on my branch and get logs.” This eliminates the need to navigate through the UI or use complex CLI commands to debug and solve problems. This is the initial release, and we will continuously be updating what the server can do over the coming weeks. If you would like to contribute, please don’t hesitate to put in a pull request.

For more details and example use cases, check out our documentation and our blog post.

For questions or feedback, please open an issue on the GitHub repository.

The “Trigger type” dropdown in the “Add trigger” form (Project Settings > Triggers) has been updated with the following changes:

• “GitHub App” is now the default pre-selected option for all organization types
• For organizations using CircleCI’s GitHub OAuth App integration, the dropdown now displays only the three valid trigger options: GitHub App, Custom Webhook, and Schedule

Similarly. the “Integration” dropdown in the “Add pipeline” form (Project Settings > Pipelines) has been updated with the following changes:

• “GitHub App” is now the default pre-selected option for all organization types
• For organizations using CircleCI’s GitHub OAuth App integration, the dropdown now only includes the option “GitHub App”

Update: Based on user feedback, this release has been postponed to better assess impact to VCS workflows. Detailed descriptions of changes and a new launch date will be announced soon. A new date for any breaking changes will be announced at least 4 weeks in advance.

Clarification - All VCS status checks are impacted.

What is changing?

Status checks previously sent skipped job statuses as failures, now they will be sent as successful checks. This is to align with GitHub’s definition of skipped status.

This means that “skipped” will not prevent pull request merging, even if it is a required check.

List workflow jobs v2 API previously returned jobs with blocked statuses for jobs that never ran, now they will return as a skipped status.

This applies to other jobs that result in a skipped status within CircleCi:

• Build parallelism too high.
• Higher priority serial group already in use.
• Non-runnable blocked job (e.g. an upstream failed job that required it to be successful).

Why are we doing this?

To improve the lifecycle of jobs and enable features such as finally jobs, all jobs will transition from blocked to one of the terminal states (success, failed, canceled, skipped, unauthorized).

When will it happen?

28th April 2025 A new date for any breaking changes will be announced at least 4 weeks in advance.

The environment variable CIRCLE_PULL_REQUEST is now populated for all pipelines triggered from GitHub, regardless of integration type, whenever the triggering commit is associated with a pull request.

For GitHub App pipelines specifically, the pipeline variable pipeline.event.context.github.pr_url is also populated with the same information.

Previously, the CIRCLE_PULL_REQUEST environment variable was only populated for pipelines that used CircleCI’s GitHub OAuth App integration.

Parameters in the trigger pipeline modal now automatically populate based on the pipeline selected in the dropdown menu at the top of the form.

Currently, this feature is only available for pipelines that are configured with CircleCI’s GitHub App integration. For pipelines that use CircleCI’s GitHub OAuth App integration, parameters continue to auto-populate based on the config file used in the most recent pipeline run, regardless of whether it matches the pipeline that has been selected.

The host OS that Docker jobs run on is being upgraded to support new features and ongoing security and bug patches. This upgrade has now been rolled out to all customers.

Learn more about this change in Discuss: Docker Executor Infrastructure Upgrade.

What is changing?

Workflows that were previously marked as not_run—due to CI skip conditions or the “only build PRs” feature flag—will no longer create pipelines. These pipelines will not appear in the UI or API. However, the trigger event will still be recorded in the audit logs.

Why are we doing this?

Showing skipped pipelines clutters the UI and API with information that’s irrelevant to users. This behavior is also inconsistent with other VCS integrations. Removing these entries increases consistency and improves the overall user experience.

When will it happen?

14th April 2025

When using the GitHub App integration, each user needs to “authorize” the CircleCI GitHub App for their pipelines to be correctly attributed to them. Not doing so means:

• their pipelines won’t have access to contexts
• their pipelines won’t run if they have enabled the setting “Prevent unregistered user spend”
• they can’t manually trigger pipelines through the UI

Previously, the “Authorize” button was only available in the Pipeline and Trigger forms - two pages that most users don’t commonly visit.

In order to make it as easy as possible for users to know that they are not “authorized” and to take action on it, we introduced a call to action on the navigation bar.

The “Authorize” button appears only when the organization has the GitHub App installed, and the current user is not yet authorized.

IMPORTANT: This change is being released incrementally to selected organizations to ensure optimal user experience before full deployment.

Effective April 1, 2025, all Japanese versions of our public documentation will be removed from the site. The language switcher will also be discontinued.

Please use the English version of these pages for the most accurate and up-to-date information about using CircleCI.

If you have questions or feedback about this change, please visit our community forum.

The host OS that Docker jobs run on is being upgraded to support new features and ongoing security and bug patches. This upgrade is being applied to jobs using Docker ARM and IP ranges from now through April 1.

Learn more about this change in Discuss: Docker Executor Infrastructure Upgrade.

We have introduced some UI changes to the pipelines page:

• The column previously named “Project” was renamed into “Pipeline”

  It displays pipeline name, pipeline number, and (only when looking at the All pipelines view) project name

• The column previously named “Trigger event” was renamed into “Checkout source”

  It continues to show the same information as before, but the avatar now shows the profile picture of the commit author, if that information is available. If it isn’t (this is currently the case for OAuth pipelines), the avatar does not show. To avoid this inconsistency, we plan on hiding the avatar also for other types of pipelines.

• A new column “Trigger event” was added

  It shows what event that triggered a pipeline (Push, Pull request, API, …). The avatar indicates who triggered the event, with a tooltip showing the username on hover.

• The headers of columns Pipeline and Trigger event each include tooltips, informing users that:

  1. it’s now possible to have multiple pipelines in the same project
  2. more GitHub trigger events options are now available

  These tooltips are visible to orgs that integrate with our GitHub OAuth app integration or GitHub App/GitLab/Bitbucket Data Center integrations. They are not visible to organizations that integrate with Bitbucket Cloud..

These changes are currently in preview, and additional improvements will be made in the coming weeks. If you have any feedback, please comment on this post on our community forum.

Runner Release 3.1.3

Machine Runner:

• Fixed a bug where an error downloading the task agent binary was not correctly propagated, causing the runner to get stuck without retrying the download and requiring a manual restart to unblock.

We’ve introduced a new project overview page, which allows users to get a quick sense of the health of their pipelines and see what changes have recently been deployed for a project all in one place. Users can access this page by clicking the Overview link from the Organization Home page or Projects page.

If you have any feedback on how we can improve this overview, please use the survey popup in the bottom right corner of the page to let us know!

The tab “VCS” in Organization Settings has been renamed into “VCS Connections”, and it now includes a section dedicated to the GitHub App integration.

If the CircleCI GitHub App is not installed, it provides an overview of the functionality enabled by the App.

If the CircleCI GitHub App is installed, it shows which GitHub organization it’s connected to, and lets admin access the configuration page

The settings button redirects to the GitHub installation page. The delete button opens a modal which requires additional user input to confirm uninstallation of the GitHub App. Both actions are restricted to organization admins only.

The queue orb was previously used to avoid multiple pipeline race conditions and conflicts. Serial-job provides native support for the functionality provided by the queue orb. Overtime we will expand the use cases we support to cover additional challenges like multi-job or workflows. The first release is serial-group for individual jobs.

This allows an individual job to be serialized across the organization, project or branch based on the parameters you provide. Serialization will ensure the jobs are executed in the order in which the pipelines are started via commit, api or other triggering method.

To learn more about your options see the documentation.

A growing number of GitHub OAuth customers have been looking to stop building their OAuth pipelines in favour of the new GitHub App pipelines which provide a broader range of triggering options.

This is currently a manual process, which requires making changes in GitHub.

To avoid users having to refer to the docs for instructions, we added a “delete” icon next to the OAuth trigger (Project Settings > Triggers), which opens a modal containing instructions for how to disable the OAuth trigger manually.

It is now possible to configure pipelines to be triggered only on pushes to non-draft Pull Requests.

Who Can Use This?

This functionality is available to all customers that use GitHub.

If your organization is currently integrated with GitHub only through OAuth, an admin must take the one-time action of installing the CircleCI GitHub App to enable this functionality.

Getting Started

1. Go to your project’s Project Settings > Pipelines, and ensure you have a “GitHub App” pipeline defined
2. Go to Project Settings > Triggers, and define a GitHub App trigger
3. In the “run on” menu, select “Pushes to open non-draft PRs”
4. Trigger your GitHub App pipeline by pushing to a non-draft PR

For more details on newly supported GitHub trigger events and example use cases, check out our documentation. For any questions or feedback, email benedetta@circleci.com.

The “Add Pipeline” form (Project Settings > Pipelines) now includes links to a Google Form that helps customers troubleshoot common issues related to GitHub App installation and permissions.

This bug has been fixed, and the note removed from the docs.

The “build forked pull request” setting in Project Settings > Advanced has been updated to clarify that it only applies to OAuth pipelines, not GitHub App pipelines.

This is an important clarification, given that organizations that use the GitHub OAuth App can now also run pipelines integrated via GitHub App to leverage new features.

The “only build pull request” setting in Project Settings > Advanced has been updated to clarify that it only applies to OAuth pipelines, not GitHub App pipelines.

This is an important clarification, given that organizations that use the GitHub OAuth App can now also run pipelines integrated via GitHub App to leverage new features.

The triggers table displayed in Project Settings > Triggers now includes two additional columns: “Pipeline to trigger” and “events”.

• Pipeline to trigger indicates the name of the pipeline associated with each trigger
• Events indicates which trigger events will cause the pipeline to run (e.g. “All pushes”, “PR opened”, “PR merged”, …)