Pipelines can now be triggered on a wider range of GitHub events, including pull request events, giving you more control over when your builds run.

The full range of trigger options available are:

• All pushes
• Tag pushes
• Pushes to default branch
• PR opened or pushed to, default branch pushes, tag pushes
• PR opened
• PR merged
• PR marked ready for review
• “run-ci” label added to PR

This allows teams to trigger builds only when needed, reducing unnecessary spending.

Customizing Triggers for Different Pipelines

This functionality can be leveraged to configure different pipelines in the same project to run on specific events. For example:

• A “build-test-deploy” pipeline (config.yml) runs on “all pushes”
• A “benchmark” pipeline (benchmark.yml) runs on “PR opened”
• A “cleanup” pipeline (teardown-env.yml) runs on “PR merged”

We plan to expand the available events and conditions to choose from. Let us know what additional triggers your team needs by filling out this form, so we can prioritize adding them next.

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 your preferred event
4. Trigger your GitHub App pipeline by performing the selected action on GitHub.

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

For any questions or feedback, email benedetta@circleci.com.

Github App organizations can now take advantage of Github Checks. Customers often use GitHub checks to verify and validate that specific jobs or workflows have been completed before taking action like merging code.

GitHub App support within CircleCI allows customers to have multiple “pipelines” defined within a single project. Github doesn’t share this same capability or concept when it comes to GitHub Checks. GitHub checks the workflow name is the key and if workflows in two different pipelines share the same name they would overwrite each other’s status. CircleCI had to introduce a way to ensure that status updates were unique and identifiable by workflow across pipelines. Because of this, we introduced a pipeline definition ID in the workflow name for GitHub Checks for GitHub App integrations. These are non-mutable and allow the organization to build GitHub Check rules that are name-based.

NOTE: Some customers have both Github App and GitHub OAuth enabled on their application and may have both Github Status and GitHub checks enabled. Those customers will see GitHub Check updates for the GitHub App integration.

There is a new “no-op” type of job available to customers, which does nothing. This is useful in some cases to shape complex workflows and simplify dependency relationships when there are large fan-in/fan-out scenarios.

Use “type: no-op” when defining a job at it does nothing.

some-job:
  type: no-op

For example, if you had a workflow for building and deploying a binary to several distribution channels you might have a configuration like this:

workflows:
  main:
    jobs:
      - build-binary
      - generate-docs
      - run-tests
      - publish-to-app-store:
          requires:
            - build-binary
            - generate-docs
            - run-tests
      - publish-to-play-store:
          requires:
            - build-binary
            - generate-docs
            - run-tests
      - publish-to-website:
          requires:
            - build-binary
            - generate-docs
            - run-tests

With the addition of a no-op job called “build” you could shape your workflow as follows:

workflows:
  main:
    jobs:
      - build-binary
      - generate-docs
      - run-tests
      - build:
          requires:
            - build-binary
            - generate-docs
            - run-tests
      - publish-to-app-store:
          requires:
            - build
      - publish-to-play-store:
          requires:
            - build
      - publish-to-website:
          requires:
            - build

This reduces duplication of requires stanzas and makes it easier to create new jobs both before and after “build” without making mistakes in the dependency relationships.

We have added conditional support to when statements so you can do things like this: when: pipeline.git.tag == "release". The conditional support allows you to run workflows based on pipeline parameters and values.

For those looking to optimize their pipelines for fast feedback or cost, you now have additional capabilities to meet those objectives. We have also made some improvements to error messaging for those customers that may have invalid config.yaml post release. The error will be similar to this: “Error calling workflow: ‘workflow-name’ Expected valid pipeline variable”.

Please see previous notifications about this breaking change here.

For more about these new capabilities visit the docs.

For organizations that integrate with GitHub App, GitHub OAuth App, Bitbucket Cloud, and Bitbucket Data Center, we now pre-populate pipeline parameters when triggering pipelines in the CircleCI web app.

For more details or to share feedback, visit our community forum.

Before Upgrading

See the CircleCI server 4.7 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.7.0

The v4.7 release introduces security improvements with the implementation of rootless containers.

NEW FEATURES

• Approval jobs can now be canceled through the CircleCI UI or via the API.
• Windows container runner preview

CHANGES

• Server components now run as rootless containers, enhancing security.
• The Nomad server ReplicaSet is now scaled to 5 pods by default, which improves execution stability at scale.
• Nomad clients require IPv6 support within the kernel.
• Configuration for the RabbitMQ PersistantVolumeClaim (PVC) is now exposed through server Helm values. For more details, see the docs.

BUG FIXES

• Resolved an issue where frontend pods would not automatically detect and apply a new server license.
• Fixed a bug where a workflow could be prematurely marked as failed before all non-blocking jobs were run.
• Fixed a configuration issue that could cause connection refusals between Kong and Soketi following an upgrade to version 1 of Soketi.
• Addressed a typo in the Helm values for machine_provisioner.machine_agent_base_url. The correct template value should be machine_provisioner.agent_base_url.

SERVICE CHANGES

Deprecated components removed with this release:

• web-ui-404: Previously served the 404 error page. Its functionality has now been merged into the main web-ui component.
• Support for GitHub Enterprise versions <= 2.2: Code supporting these versions has been removed, as they are no longer supported by GitHub.

DATABASE MIGRATIONS

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

• authenticationservice
• conductor_production

KNOWN ISSUES

• SSH reruns in air-gap will time out, leaving the job in an error state
• Vault may not refresh its client token after a month of uptime. Migrate to Tink to resolve this issue.
• Retry with SSH for jobs using the machine executor advertises a private IP address. For this reason, retry with SSH for jobs using the machine executor works as standard for public installations, but for private installs you would need to ensure that you can access the private IP advertised. For example, by using a VPN into your VPC.
• CircleCI 1.0 builds are not supported. If an attempt is made to run a 1.0 build, no feedback will be available in the application to indicate the cause of the issue. If a build is run on your installation and does not show up in the CircleCI application, use the CircleCI CLI to validate the project configuration and get details of the possible cause of the issue.
• Machine builds using instances with IMDSv1 enabled is not supported

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

Historically, CircleCI users have been limited to setting up validation systems that only worked within the scope of a single repository.

If a pipeline’s YML config was stored in Repo A, that pipeline could only be triggered from events on Repo A (or from a Custom Webhook). This has left many customers unable to set up the validation system that they want.

We have launched additional enhancements to pipeline and trigger configuration, which will enable customers to build any validation setup that they need.

Read more on our community forum.

We are enabling users who are a part an organization that integrates with CircleCI’s GitHub OAuth App to use functionality that was previously only available to organizations that integrate with CircleCI’s GitHub App.

The immediate change that users will see is the presence of “Pipelines” & “Triggers” tabs in Project Settings of the CircleCI web app.

Read our community forum for details.

Until today, the Pipeline property “Fallback branch” determined which branch would be used to fetch config and code for pipelines triggered via Custom Webhook. This field could only be configured by editing the Pipeline associated with a Custom Webhook, rather than by editing the Custom Webhook itself, and was poorly discoverable.

Now, the field “Fallback branch” has been removed from Pipeline configuration, and two new fields have been added to Custom Webhook setup:

• Config branch, which determines the branch to be used to fetch config
• Checkout branch, which determines the branch to be used to check out code when running a checkout step.

For existing custom webhook triggers, both new fields have been populated with the “fallback branch” value of the associated pipeline, so that existing behaviour is preserved.

Pipelines connected via GitHub App or Bitbucket Data Center can now be run via API, using a new API V2 endpoint:

https://circleci.com/api/v2/project/circleci/<org-id>/<project-id>/pipeline/run

See the docs for usage instructions. The new endpoint is not yet documented in the V2 API docs.

With CircleCI’s Evals orb 1.x.x, users were able to configure CircleCI to orchestrate evaluations of their LLM-enabled applications within their CI pipeline.

Evals orb 2.0.0 builds upon version 1.x.x, introducing Evaluation Testing. With Evals orb 2.0.0, users are able to automate the entire process of running evaluations, reviewing evaluation results and determining whether results meet application performance criteria. This removes the need to manually trigger evaluations and manually review evaluation results. Automating evaluations with CircleCI enables developers to automatically determine whether or not to merge proposed changes, or deploy their AI application.

To use Evaluation Testing, users configure test cases to determine if the results of an evaluation meet specified conditions. Each test case represents a scenario with an assertion to check if a specified condition is true or false. If any test case fails, the evaluation test fails. You can configure test case assertions such as Thresholds (Check whether 1 or more results fall within a range), and Equality (Check whether results provide an expected answer)

Evaluation Testing results are presented in the CircleCI web UI in two locations:

1. In the step details
2. In the tests tab

We have added release markers and release jobs to CircleCI Releases!

Release markers provide a lightweight way for users to generate a changelog and easily track their releases without requiring a full CircleCI Releases setup (no agent install needed!). Release markers can be configured for releases to any deployment target (ie. ECS, EC2, VMs, k8s, etc). See our documentation for information on setting up release markers.

Release jobs replace kubernetes manifest annotations as the way to configure deployment triggers. Release jobs also allow users to monitor their kubernetes release process as part of the overall deployment workflow in CircleCI, making it easier to find releases for a given pipeline. Users can also use release jobs to orchestrate releases across multiple environments (for example, deploy to production only after a successful release in a staging environment). See our documentation for information on setting up release jobs.

This version will reach EOL in August 2025 and can be skipped when upgrading from 4.3 or 4.4. We recommend upgrading directly to 4.7 for the latest security patches.

Before Upgrading

See the CircleCI server 4.6 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.6.0

The v4.6 release introduces various UI refreshments and improvements.

NEW FEATURES

• Several enhancements to the CircleCI web app, including:
  • A new “User Homepage”.
  • Updated styling for the left-hand navigation bar.
  • Top navigation bar that allows easy access to user-level actions.
• Pipelines are now labeled whenever they are rerun from start or fail, or with SSH.
• Project-based context restrictions. For more information see the docs.

CHANGES

• Old, expired workflows are now automatically canceled after 90 days.
• The pipeline.in_setup pipeline parameter has been removed.
• Kong, which is used for server API management, has been upgraded from 2.x to 3.x.

BUG FIXES

• Fixed a bug that prevented jobs from being rerun with SSH.
• Resolved an issue that prevented project loading on the Insights dashboard.
• Addressed regressions from server 4.2:
  • Introduced a configuration option at the organization level to set the default resource class for a Docker job. In server 4.3, this was previously hardcoded to large.
  • Added support for absolute paths in defining a GCP network under the machine provisioner configuration. This feature is particularly useful for VM jobs using shared networks, enabling explicit network selection. This corrects a regression from the previous VM service architecture.

NEW SERVICES

New services introduced with this release:

• authentication-service - provides an interface for user and identity management in the CircleCI system

DATABASE MIGRATIONS

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

• builds_service
• conductor_production
• permissions

KNOWN ISSUES

• SSH reruns in air-gap will time out, leaving the job in an error state
• Vault may not refresh its client token after a month of uptime. Migrate to Tink to resolve this issue.
• Retry with SSH for jobs using the machine executor advertises a private IP address. For this reason, retry with SSH for jobs using the machine executor works as standard for public installations, but for private installs you would need to ensure that you can access the private IP advertised. For example, by using a VPN into your VPC.
• CircleCI 1.0 builds are not supported. If an attempt is made to run a 1.0 build, no feedback will be available in the application to indicate the cause of the issue. If a build is run on your installation and does not show up in the CircleCI application, use the CircleCI CLI to validate the project configuration and get details of the possible cause of the issue.
• Open ID Connect Tokens are not generated and not available.

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

m1 medium is now the default resource class for Performance and Scale Plan customers. This applies only to jobs that do not have a resource class specified.

Update jobs using gen2 medium by June 28 to avoid failing builds. Learn more.

The official CircleCI Evals Orb makes it easy to integrate LLM evaluations into a CI pipeline, and to review evaluation results without context switching. The output of evaluations run through the Evals Orb is stored in CircleCI, and is accessible as a job artifact and as a PR comment added automatically by CircleCI.

Currently, the Evals Orb exposes commands to run evaluations through two popular LLMOps tools: LangSmith and Braintrust. If your evals leverage a different tool, let us know at ai-feedback@circleci.com. You can also contribute directly to the official Orb, by opening a PR on the public repository.

More resources on evaluating LLM-enabled applications are available in our documentation.

Get access to all your CircleCI usage data via our Usage API.

Query your usage data for any 32-day window (or less) going back up to 13 months. Data is refreshed daily through the previous full day. Understand your pipelines, workflows, and jobs, your credit consumption and RAM/CPU utilization on the job run and much more.

Hit the API to query your data, get back a link from which you can download a CSV, then load it into a data warehouse of your choice for deep CircleCI usage analysis.

For more information, check out our documentation.

Expression based context restrictions enable developers to restrict contexts based on pipeline values such as branch, ssh rerun and other attributes of the pipeline. This provides greater control over context access for things like contexts only available to production branches, builds run by specific actors and more. For security concerned and complex workflows customers are able to limit access to contexts to meet their specific security needs.

General documentation and API documentation are available to learn more.

With the launch of our release agent 1.0.0, CircleCI releases is now generally available. Installing the release agent in your kubernetes cluster gives users org-wide visibility into all components and releases via the Releases UI.

Our agent also integrates with Argo Rollouts to give customers more visibility and control over their progressive releases and use analysis runs to fully automate their release process based on observability metrics. Check out our docs to learn more!

CircleCI’s Visual Studio Code extension now lets customers trigger pipelines from VS Code based on local, unversioned configuration files. Users can choose to run a full pipeline, or select only the individual jobs and workflows they want to run by using checkboxes. This will shorten the feedback cycle and enable developers to iterate fast on their configuration, without having to commit their trial and error changes to the VCS.

This feature is controlled by an org-level opt-in setting, and an opt-out project level setting.

Check out the feature docs for more information.

Container Runner SSH Rerun (Preview)

Container runner now supports SSH Rerun. Visit our documentation on setup and usage.

For more information on SSH rerun please see the following documentation.

Users can now orchestrate their model deployments across multiple environments through the Amazon SageMaker Orb. They can also track and manage their deployments from within the Releases UI.

See our documentation for more information.

Inbound Webhooks are now available in open preview.

With this new feature, you can trigger a pipeline from anywhere that emits a webhook or run a curl command. With this change, we also updated pages such as the Dashboard to accurately reflect that pipelines can now come from outside your VCS.

Only available to users authenticated through our GitHub App integration. See our community forum and an AI use case for more.

Now in preview, three new resource classes that use GPUs:

1. gpu.nvidia.small.gen2: uses 1 NVIDIA Tesla A10G GPU (4 CPU / 16 GB RAM 200 credits/min)
2. gpu.nvidia.small.multi: uses 2 NVIDIA Tesla T4 GPUs (4 CPU / 16 GB RAM 160 credits/min)
3. gpu.nvidia.medium.multi: uses 4 NVIDIA Tesla T4 GPUs (8 CPU / 30 GB RAM / 240 credits/min)

Only available to users on our Scale pricing plan. See our community forum for more.

Upon encountering a failed step, users now can solicit guidance at the press of a button. This takes away the need to copy and paste the error message into your favorite search engine to find out what the problem might be and how to fix it.

Admins can opt out of this experiment by navigating to the Advanced section of Organization Settings.

The feature is powered, currently, by OpenAI. The only data sent to OpenAI is the error message in the output from the failed step. Before the message is sent any sensitive information such as passwords or access keys is removed. None of the data provided is being used to train the model.

Let us know what you think in the Discuss thread.

What’s New

CircleCI now offers Apple Silicon M1 support on our macOS executor. Customers on annual plans can take advantage of the improved performance by updating their config to resource_class: macos.m1.large.gen1.

Learn more by reading our announcement and documentation.

What’s New

Visual Studio Code users can now re-run CircleCI jobs with SSH, through either the integrated terminal, or a dedicated remote development window. You can automatically open an SSH connection within the terminal, or use a remote window to work on a CircleCI remote machine as if it was a VS Code workspace, which allows you to browse and view files easily, as well as take advantage of supported extensions.

For more details, see the Discuss post (including a quick demo), or the docs on VS Code Marketplace.