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”, …)

Runner Release 3.1.2

Container Runner:

• Set resource requirements (requests and limits) on the orchestrator init container (https://github.com/circleci/runner-init). This change helps ensure the Pod is schedulable when resource quotas are applied.
• Added options to configure the image name for the orchestrator container. This can be used for hosting the image in a private registry or within an air-gapped environment on CircleCI server. Note this change requires version v101.1.3 of the Helm chart.

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.

Runner Release 3.1.1

Container Runner:

• Fixed the volume for GOAT and task-agent binaries to be read-write. It was unnecessarily read-only and caused issues with the circleci-cli orb, which overwrites the circleci symlink with the CLI.

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.

By Aakar Shroff

Our teams spent 2024 focusing on allowing you maximum flexibility in how you do work on CircleCI. It’s hardly an exaggeration to say that for every customer on CircleCI, there is a unique way to configure and run a pipeline – and that’s a good thing! From VCS-triggered events and filters to different places that config can live and what can be done with it, to new and expanded options for resources classes… you wanted increased flexibility, and in 2024, we delivered.

In that spirit, we want to take a moment to share some key features designed to bring you even more power and value. We launched Releases, an integrated platform to manage, modify, and monitor software deploys, helping you push changes faster and with more control than ever. We also created custom webhooks, letting you set triggers in the way that best suits your team, and enabling fine-tuned control over your workflows. We also expanded GitHub apps features for OAuth, ensuring smoother integrations and tighter security. The release of the CircleCI Eval orb (reusable package of YAML configuration) broke new ground for developers working on testing AI-based applications. The launch of the Usage API has redefined visibility, helping customers track usage data, allowing more control of resource management and cost. Finally, our introduction of expression-based contexts made workflow execution more flexible than ever before, enabling new variables in your pipeline to control access to shared resources.

Each release we have brought to our community over this past year has been shaped by our continued dedication to maximize productivity, efficiency, and control in your software delivery.

Want more? Here are some highlights from 2024:

Dev experience

• We decreased load times on the Pipelines page significantly (30%-100%), benefitting customers who were experiencing slow loading due to running higher numbers of projects (~20+ pipelines with 15+ jobs per workflow).
• By merging our frontends into a single repository, we can deliver new features more quickly and efficiently and continue to improve accessibility.

Payments and billing

• We transitioned to Stripe, to bring you a notably robust and reliable payment provider. This transition enabled us to provide you with flexible plan options - ability to pay past due bills and seamlessly toggle between month-to-month and prepaid billing, without any requirement for support assistance.

Data reliability

• We improved how we manage databases, adding blue-green deployments to drastically reduce customer downtime when making updates.
• We built a historical database to allow faster access to data, to improve the customer experience wherever we display customer build information (Insights, jobs, pipelines, or other metrics).

Resource classes

• We added HTTPS Checkout to improve the ease of use on setup for GitHub App integrations.
• We shipped M2 Pro resource classes: M2 Pro Large and M2 Pro Medium. These releases offer a sizeable performance boost over 1st generation M1 Mac mini hardware.
• We moved the Mac fleet to a new architecture that will allow us to scale faster to meet customer demand.
• We improved the speed and reliability of Xcode image distribution: new versions of Xcode now become available faster.

Identity management

• We released user groups that introduce more granular controls for project-level permissions. Available for orgs connected to GitHub App, Gitlab, and BitBucket Data Center.
• We released SSO, supporting identity providers like Okta and Ping Identity for standalone organizations who want to control CircleCI access from a central location.
• We now allow SSH reruns for standalone users. Users can store their public SSH keys inside CircleCI (in authentication-service), allowing SSH reruns to work for customers who are a part of an organization that uses CircleCI’s GitHub App, Bitbucket Data Center, or GitLab integrations.
• We made some architectural changes to our authentication and authorization services to make validating access faster for customers.
• As part of that, we have increased the reliability, scalability, and serviceability of those services to allow us to add new features and functionality to our access and authorization services.

Server and runners

• We significantly increased the performance, resilience, and reliability of self-hosted runner container jobs, allowing customers to use their infrastructure and resources better for CircleCI jobs.
• Server components now run rootless, reducing the vulnerability surface area of the various components that run in-server.
• Server now includes high-value security features such as OIDC, and config policies.
• We enabled customers to directly update to the latest version of server (4.7) from any version since 4.3, providing a clear path for customers to be running the most recent version.

Configuration

• We are now able to add new config syntax and capabilities quickly and safely. That enabled us to do things like flexible requires, when statements for jobs, and parameterized filters. These additions allow customers to optimize pipelines and workflows for speed and cost.
• Config compilation time was reduced by 4x, solving timeout issues for complex configurations. This decreases time to feedback for customers and reduces failed pipelines run.
• We optimized how we compute workflow statuses, improving API latency by 3x, which improves user experience on Insights, the API v2, and the UI.

Platform reliability

• We’ve continued to invest in scalability and reliability improvements, and thanks to these investments, we maintained uptime above our target.
• Automated Rollbacks: Using analysis templates, we can now automatically revert deployments with increased error rates, enabling faster detection and resolution of issues.
• Synthetic testing: We prioritized synthetic tests, particularly for integrations across different sources of change, ensuring accurate data flow and downstream execution for customer needs.

We have had a record year of building software (and according to our data, you have too). From our team to yours, we thank you for trusting us to be a part of your engineering organization this year. We look forward to working with you to help you and your team deliver even better in 2025.

In the Manage tab of the Plan page in the CircleCI web app, the copy has been updated for clarity.

Before: “Free Support: 8x5 with prompt responses” After: “Free Support: Access to support articles & community forum”

See our support article for the latest details on CircleCI’s support offerings.

The custom webhook URL displayed in the “Edit Custom Webhook Trigger” form was incorrectly showing undefined where the trigger ID was supposed to be. This has now been fixed.

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.

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.