CircleCI is updating the underlying infrastructure for its CircleCI web app that powers the User Settings pages. No negative impact is expected, however, if you see anything that looks like unexpected behavior in the User Settings pages, email me at sebastian@circleci.com.
We are making some changes to when statements for workflows December 3rd. We will be adding conditional support to when statements so customers can do things like when: pipelines.git.tag == release. This conditional support allows for customers to run workflows based on pipeline parameters and values.
We are making some changes to when statements for workflows December 3rd. We will be adding conditional support to when statements so customers can do things like when: pipelines.git.tag == release. This conditional support allows for customers to run workflows based on pipeline parameters and values.
NOTE: When in Steps are not impacted by this change.
If you currently have when: always in your workflows you will need to make a change to your config. Always has never been a special value for workflow when, it is a non-empty string and currently evaluates as true. This is equivalent to removing the when key from your workflows.
Shortly the “always” string will be interpreted as an expression and will fail. To avoid your config failing to be processed you must remove the when from your workflows, which is equivalent to the prior behaviour.
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 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.
The “Delete Docker Layer Cache Content” button in Project Settings of the CircleCI web app was occasionally not working as expected. This has now been fixed.
A change has been made to the underlying infrastructure that powers the “Pipelines” page of the CircleCI web app, specifically the infrastructure that powers the tooltips on the page. Reach out to sebastian@circleci.com if you are experiencing any issues with the tooltips on the page.
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.
The host OS that Docker jobs run on has been upgraded to support new features and ongoing security and bug patches. This upgrade will roll out to all customers over the next few weeks. We do not expect any negative impact. Learn more about this change in Discuss: Docker Executor Infrastructure Upgrade.
We resolved a bug that was preventing users from clicking the ‘Run Pipeline’ button on smaller screen sizes. All users can now access the button by scrolling within the modal.
The ability to trigger pipelines in the CircleCI web app is now available for organizations that integrate through GitHub App and Bitbucket Data Center. Users can access this functionality by navigating to the Pipelines page and clicking the ‘Trigger Pipeline’ button, located on the top right of the page. This functionality is not yet available to organizations that integrate through GitLab.
Organizations that integrate with GitHub OAuth and Bitbucket Cloud will see a revamped experience to the existing modal.
As part of enabling users to more flexibly trigger work, the output of the “checkout step” in the CircleCI web app now shows the repository that is being checked out during the execution of the job. This is helpful for scenarios where the repository being checked out does not match the repository where the configuration file lives and/or the repository of the trigger event.
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 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.
A bug has been fixed which prevented users from viewing all Bitbucket Data Center pipelines as options when creating a Bitbucket Data Center trigger. All pipelines are now available to be selected.
In Project Settings > Pipelines of the CircleCI web app, the org name has been removed from the “Config Source” column to remove unnecessary information and improve the readability of the page.
The “checkout source” is no longer editable if a pipeline has associated triggers in the “Edit Pipeline” form in Project Settings of the CircleCI web app.
This was done to avoid getting into a state which would result in error pipelines being generated if the pipeline’s checkout source was edited to use a different repo.
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.
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.
Minor changes have been made to the order in which items are presented in the “Add” and “Edit” forms for Pipelines & Triggers in Project Settings of the Circle web app to streamline the user experience.
A new v2 API endpoint for triggering pipelines via API is now available to all organizations that integrate through GitHub (GitHub OAuth and GitHub App) and Bitbucket (Cloud and Data Center). This functionality is not yet available to organizations that integrate through GitLab.
A new v2 API endpoint for triggering pipelines via API is now available to all organizations that integrate through GitHub (GitHub OAuth and GitHub App) and Bitbucket (Cloud and Data Center). This functionality is not yet available to organizations that integrate through GitLab.
The endpoint is:
POST /api/v2/project/{provider}/{organization}/{project}/pipeline/run
This is now the recommended API to be used to trigger pipelines.
The pre-existing endpoint for triggering new pipelines - which is only available to organizations integrating through GitHub oAuth or Bitbucket Cloud - continues to be supported.
The “Edit Pipeline” form in Project Settings of the CircleCI web app did not have a field to show whether a user can properly use the rest of the form via a VCS connection. This led to confusing error messages when users were not properly connected.
This issue has been fixed by putting the “connection” field in the form.
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.
Job Filters now support expression based conditions, much like contexts. This enables you to conditionally run jobs based on pipeline values. This supports you optimizing pipelines to lower costs, decrease time to feedback, or run specific jobs based on context of the source of change. Previously filtering was extremely limited to branches and evaluating to only and ignore.
Job Filters now support expression based conditions, much like contexts. This enables you to conditionally run jobs based on pipeline values. This supports you optimizing pipelines to lower costs, decrease time to feedback, or run specific jobs based on context of the source of change. Previously filtering was extremely limited to branches and evaluating to only and ignore.
We will be following on this with expression based evaluations for When Statements which enable more flexibility in how you choose when steps or workflows run. When Statements are also currently limited in their evaluation options. Improving When Statements will expand your options optimizing for cost and speed.
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.
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.
GitHub App users who granted their App access to more than 100 repositories have been running into issues when creating Pipelines and Triggers on CircleCI, because the repository dropdown would only display a limited number of repositories.
GitHub App users who granted their App access to more than 100 repositories have been running into issues when creating Pipelines and Triggers on CircleCI, because the repository dropdown would only display a limited number of repositories.
We have now replaced the dropdown inputs with a search component, which lets users search repositories by keyword.
Note: at the moment the search results include all of an organization’s public repositories. We plan to adjust this behaviour in the near future.
frontend pod will now redeploy when the circleci license has been changed
the timeout for windows and linux machine instances can now be configured using machine_provisioner.terminatePendingWindowsAfter and machine_provisioner.terminatePendingLinuxAfter respectively in your values.yaml
fixed table ownership issue which prevented insights data from loading
frontend pod will now redeploy when the circleci license has been changed
the timeout for windows and linux machine instances can now be configured using machine_provisioner.terminatePendingWindowsAfter and machine_provisioner.terminatePendingLinuxAfter respectively in your values.yaml
nomad server pod replica count will now default to 5
Frontend pod will redeploy when license updates are made
The timeout for windows and linux machine instances can now be configured using machine_provisioner.terminatePendingWindowsAfter and machine_provisioner.terminatePendingLinuxAfter respectively in your values.yaml
Custom webhooks let you trigger pipelines from any 3rd party that can emit an outbound webhook. This functionality is now available to orgs that integrate with CircleCI’s GitHub OAuth App. Read more about how to use custom webhooks in an organization that integrates with CircleCI’s GitHub OAuth App.
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.
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.
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.
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.
There was an edge case where the “Branch” field in the Releases UI in the CircleCI web app was not getting populated correctly. This has now been fixed.
On the “All Pipelines” page of the CircleCI web app, the “Trigger Event” column now has slightly different formatting for pipelines that are triggered via CircleCI’s GitHub App integration.
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.
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:
