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.

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.

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

CircleCI will be moving to twice-yearly major and minor version releases of Server. Releases will be targeted for Spring (April) and Fall (October). Patch releases for bugs and security updates will be made monthly as needed.

We will support two minor releases or 1 year from the date of the release. This is a change from the current 4 minor releases or 1 year from the date of the release. After the April release of server 4.8, supported versions of server will include server 4.8 and server 4.7.

A catch-up release will be made available in the coming months that will allow existing customers to upgrade from 4.3, 4.5, and 4.6 variations to the most recent server version 4.7. Allowing customers to get to a supported version before we release 4.8 in April.

Server release 4.8 is planned to include some new features. The first enables more flexibility in defining which jobs or workflows run using conditional expressions. The second is the introduction of an observability stack that will enable proactive monitoring of the state of the server installations.