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.

Orbs are the leading method to abstract away shared aspects of your pipelines. They make it possible to simplify the complex, share, and maintain jobs and commands across your organization. For large organizations, private orbs cab provide efficiency and scale.

Orb security settings now allow organizations to enable only private orbs. Previously orb settings required enabling uncertified orbs in order to enable private orbs. This prevented some organizations, whom were concerned about uncertified orb security, from benefiting from the private orbs.

For more information on orbs and creating your own private orbs see our documentation.

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

Runner Release 3.0.25

Both Machine and Container Runner:

• Sign docker manifests to be verified with the CircleCI Public Key
• Security fixes
• Increase time between deleting existing task-agents to prevent unexpected removals during task execution

Machine Runner:

• Set KillMode=process for linux based machine runners

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.

We’ve added additional meta data using the “tag” key to audit logs to help customers identify how workflow reruns were triggered.

Workflow tags include:

• setup
• rerun-single-job
• rerun-workflow
• rerun-workflow-from-beginning
• rerun-workflow-from-failed
• rerun-workflow-from-job-ids-sparse-tree
• rerun-single-job-with-ssh

Example audit log entries

Workflow Started:

workflow.start
{"job":{},
 "workflow":{"id":"247...","name":"test-and-build","tag":null}}

workflow.job.context.request
{"job":{"context_uuids":[],"contexts":[],"id":"408...","job_name":"test","job_status":"pending"},
 "workflow":{"id":"247...","name":"test-and-build","tag":null}}

workflow.job.start
{"job":{"contexts":[],"id":"408...","job_name":"test","job_status":"running"},
 "workflow":{"id":"247...","name":"test-and-build","tag":null}}

workflow.job.finish
{"job":{"contexts":[],"id":"408...","job_name":"test","job_status":"failed"},
 "workflow":{"id":"247...","name":"test-and-build","tag":null}}

Retry the original workflow with rerun job with SSH enabled:

workflow.retry
{"job":{},
 "workflow":{"id":"247...","name":"test-and-build","tag":null}}

SSH enabled rerun started:

workflow.start
{"job":{},
"workflow":{"id":"811...","name":"test-and-build","tag":"rerun-single-job-with-ssh"}}

workflow.job.context.request
{"job":{"context_uuids":[],"contexts":[],"id":"c6a...","job_name":"test","job_status":"pending"},
 "workflow":{"id":"811...","name":"test-and-build","tag":"rerun-single-job-with-ssh"}}

workflow.job.start
{"job":{"contexts":[],"id":"c6a...","job_name":"test","job_status":"running"},
 "workflow":{"id":"811...","name":"test-and-build","tag":"rerun-single-job-with-ssh"}}

workflow.job.finish
{"job":{"contexts":[],"id":"c6a...","job_name":"test","job_status":"canceled"},
 "workflow":{"id":"811...","name":"test-and-build","tag":"rerun-single-job-with-ssh"}}

The pipelines page can load slowly for some users. The number of pipelines and number of projects can contribute to that slowness. A recent change to one of the underlying data services has been made resulting in a 30%-40% improvement in performance.

We continue to work on improving the pipelines page experience. Our current focus is on load time. We do have plans to introduce new filter and search capabilities in the future.

We have added an API and UI component to approval jobs that allows you to “cancel” the approval job. Previously it was not possible to cancel approval jobs. This limitation forced you to either approve the job or let it expire, which takes 90 days. This led to a suboptimal experience with jobs left in a non-terminal state. This could impact performance metrics, as well pipelines views. It also led to non-intuitive actions being taken like cancelling the workflow which cancels all remaining jobs.

We are following up this feature with more flexible require statements. So you can have a job depend on an approval while another depends on cancellation. This is great for cleanup jobs, notifications, or other tasks that may only need to happen or not happen upon cancellation.

Previously, when processing a configuration file, CircleCI would process all workflows defined in the workflow. Upon completion of processing, errors such as missing or undefined parameters would be included in feedback.

CircleCI will no longer process workflows defined in a configuration file that aren’t going to be run. This means errors that might exist within that workflow will also not be caught and reported back to the user.

During development or troubleshooting, users should ensure a workflow has run, and it’s free of any errors. This can be done by making sure any conditionals like when: <complex condition> are replaced with when: true.

As previously reported https://circleci.com/changelog/launch-agent-1-x-variants-eol/.

Support for all 1.x variants of runner launch agent has ended. It has been replaced with Machine Runner 3.0. Any remaining access will be removed September 17th, 2024. For those that haven’t migrated, your builds on runner will fail.

You can learn more about machine runner and migration here.

For CircleCI organizations that integrate with GitLab or GitHub App:

• The user count on the People tile reflects the number of users in the organization instead of active users in the billing period.

• Organization admins have the ability to invite additional teammates directly from the Organization Homepage by clicking the “Invite your teammates” button.

The CircleCI Automation Actor will be used to attribute automated workflow and job cancelations on September 17th, 2024. This change will impact two functionalities:

• Auto-cancel redundant workflows
• Jobs canceled via the v1 Cancel Job API using a project token

This change is intended to better indicate that the action was performed by a machine.

Once the change is completed, the canceled_by field of the getWorkflowById and the listWorkflowJobs API response will return the CircleCI Automation Actor ID. You only need to take action if you rely on this field to have a static value.

Users who had more than ~200 repositories in their GitHub organization & integrated with CircleCI’s GitHub App were hitting a timeout error when setting up a new project that required them to select one of their repositories.

To resolve the timeout, we reduced the number of repositories displayed in the CircleCI UI to be the 100 most recently used repositories.

We have just released a change to the project creation flow in the CircleCI UI that enables searching through all GitHub repositories without any timeout errors, not just the 100 most recently used repositories.

We will be removing the vcs_branch field from the payload column in following audit events:

• workflow.start
• workflow.error
• workflow.job.finish
• workflow.job.context.request
• workflow.schedule.start

The field has been moved to a new event associated with each pipeline named trigger_event.create.

Audit logs are exported in CSV format. Currently workflow.start event payload column looks like this:

{“job”:{},”workflow”:{“id”:”00000000-0000-0000-0000-000000000000”, “name”:”test-and-build”,”vcs_branch”:”my-feature-branch”}}

After September 21, 2024, any future event will not include the vcs_branch field, all existing events will remain unmodified:

{“job”:{},”workflow”:{“id”:”00000000-0000-0000-0000-000000000000”, “name”:”test-and-build”}}

The VCS data has been moved to a new trigger_event.create event payload column that is recorded for each created pipeline:

{“pipeline_id”:”00000000-0000-0000-0000-000000000000”, “config_source”:”vcs”, “trigger_source”:”webhook”, “branch”:”my-feature-branch”, “tag”:”my-tag”}

If the vcs_branch field in the payload column is used, customers will need to update their usage to point to the new trigger_event.create, otherwise no action is required.

Previously: The pipeline.trigger_parameters.webhook.body pipeline value was only populated when a custom webhook triggered the pipeline. If a config used pipeline.trigger_parameters.webhook.body and the pipeline was triggered with a GitHub App event, an errored pipeline would occur. This made it difficult to use one configuration file with a custom webhook & GitHub App triggers.

New behavior: The pipeline.trigger_parameters.webhook.body pipeline value will be populated with an empty string if the pipeline is triggered from a GitHub App event. This simplifies using one configuration file with a custom webhook & GitHub App triggers.

On or shortly after August 30, 2024, all new users who sign up for CircleCI with an email/password account (the default sign-up method) will be required to verify their email immediately after CircleCI account creation.  

Users will not be able to proceed into the CircleCI application unless they verify their email. This will apply to users who are creating new orgs and users who are joining their teammates in an existing CircleCI organization.

CircleCI machine images have been updated with the latest software versions. Learn more about these changes:

• Ubuntu
• Windows
• Android

Users who had more than ~200 repositories in their GitLab.com organization were hitting a timeout error when setting up a new project that required them to select one of their repositories.

To resolve the timeout, we reduced the number of repositories displayed in the CircleCI UI to be the 100 most recently used repositories.

We have just released a change to the project creation flow in the CircleCI UI that enables searching through all GitLab repositories without any timeout errors, not just the 100 most recently used ones.