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.

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.

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.

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.

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.

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.

Runner Release 3.1.0

Container Runner:

• Version 3.1.0 introduces substantial performance and reliability improvements to container runner. These updates are designed to enhance the overall efficiency and stability of operations at scale. For more background and technical details on these changes, you can visit our Runner Init repository and documentation.
• To upgrade, ensure that the Helm chart is at least version v101.1.2. The chart is pinned to the major version tag of the runner, enabling automatic upgrades on redeployment. If you wish to remain on the existing architecture (3.0.x), you can do so by setting the tag to kubernetes-3.0. This version will continue to receive only critical bug fixes and security patches. You can check the configuration details in the Helm chart repository.

Customers have been asking for more flexibility when building dependency requirements between jobs. To date “requires” was based on the success of the required job. That is no longer the case. “Requires” now supports job status; success, failed, and canceled. So you can now build out complex dependency maps and fan in/out scenarios.

• When running complex fan-in/fan-out workflows, you may want to continue work even when there are test failures.
• When certain jobs fail or are canceled, you may want to execute cleanup jobs, or decide not to do a deployment.

Example Config

jobs:
      - a
      - b
      - c:
          requires:
            - a canceled
            - b:
              - failed
              - success
      - d:
          requires:
            - a: #defaults to success
            - b:
              - failed
              - success

Flexible requires, along with flexible when statements and expression based job filters, opens up more opportunities to optimize your pipelines for fast feedback and greater control of costs.

For more information on the feature visit the documentation.

The page Organization Settings > Overview now includes a new “Organization slug” section, which lets users view and copy in one click the slug of their organization.

Please note that all the following slug formats are valid:

• github/org-name
• bitbucket/org-name
• circleci/FMckQH4sfM6PsIPQEG1RLd

Updates:

• We’ve removed the ‘Scheduled Pipelines’ tab from Project Settings and added the ability to create scheduled pipelines via the ‘Trigger Type’ dropdown on the Project Settings > Triggers page.
• For users in organizations that are integrated with GitHub OAuth App, we have added a note on the ‘Add Trigger’ and ‘Add Pipeline’ pages that states they can now use GitHub App pipelines, triggers, and custom webhooks.
• If a user does not have a GitHub App pipeline for their project, we display a message on the Project Settings > Triggers page to direct users to create a GitHub App pipeline first before they can create a GitHub App trigger.
• When users delete a trigger, we’ve implemented an automatic page refresh so the deleted trigger is immediately removed from the list.

The pipeline value pipeline.trigger_parameters.webhook.body is now present for all GitHub App and Bitbucket Data Center pipelines, no matter how they are triggered.

This value was previously undefined for pipelines triggered via API, UI, or via Bitbucket Data Center push. This prevented customers from using this pipeline value in their config file if they wanted their pipeline to be triggerable from these event sources as well as from a custom webhook.

For pipelines triggered via custom webhook, the value of pipeline.trigger_parameters.webhook.body is the stringified event payload. For all other methods of triggering, the value is now set to {}.

NOTE: This value is still not set for OAuth pipelines.

Updates:

• Added a ‘Remove all’ button to allow users to easily remove parameters for specific projects
• We display in-modal error states when users input duplicate parameter names, have a missing config file in their selected branch, etc.
• When users manually add a parameter, the new row will now appear at the top of the list instead of the bottom, making it easier to spot and fill in

GitHub App triggers, previously uneditable, can now be edited.

Specifically, users can edit the following fields:

• Trigger name
• Config branch (if present)
• Checkout branch (if present)

Updates:

• For projects with a single pipeline, the modal now defaults to that pipeline, so users no longer need to select it from the dropdown
• Automatically populate the branch in the dropdown when users are on the Project > Branch page
• Added the ability to search in the branch dropdown within the modal
• Rolled out a fix so the text no longer duplicates when users copy and paste into the parameter inputs

The page Project Settings > Overview now includes a new “Project Slug” section, which lets users view and copy in one click the slug of their project.

Please note that both the following project slug formats are valid but mutually exclusive by project:

• github/org-name/project-name
• circleci/FMckQH4sfM6PsIPQEG1RLd/4CNEcx&6Yk6wkpwo2ft9Uo

IP Ranges now support parameters providing more dynamic control of when ip ranges is used in builds.

Example

version: 2.1

parameters:
  ip_ranges:
    type: boolean
    default: true

executors:
  base:
    docker:
      - image: cimg/base:stable

jobs:
  job_a:
    executor: base
    circleci_ip_ranges: << pipeline.parameters.ip_ranges >>
    steps:
      - run: echo "Running job a"

workflows:
  workflow-a:
    jobs:
      - job_a

As a continuation of CircleCI’s update to enable access to “GitHub App functionality” to all CircleCI users (including users of the GitHub OAuth App integration), the “Triggers” tab in Project Settings of the CircleCI web app now shows a “GitHub OAuth App” trigger and a badge to indicate the integration type. This is intended to make it easier for all users to understand what is currently set up within their CircleCI project.

As part of CircleCI’s update to enable access to “GitHub App functionality” to all CircleCI users (including users of the GitHub OAuth App integration), the “Pipelines” tab in Project Settings of the CircleCI web app now shows a “GitHub OAuth App” or “Bitbucket Cloud” pipeline and a badge to indicate the integration type. This is intended to make it easier for all users to understand what is currently set up within their CircleCI project. A subsequent update will do the same for the “Triggers” tab.

Known issues: The organization name will be removed from the “Config Source” column to only show the repository name.