The installable version of CircleCI 2.8.0 includes the following fixes and improvements:
An issue involving pre-allocated remote docker, machine VM creation, and other VM usage on AWS when the on-host VM option is selected has been fixed.
An issue with the VM provider timing out when waiting for SSH to connect has been fixed. This upgrade supersedes any custom values for the Number of SSH attempts for starting VM setting and adds an equivalent field named Timeout for waiting for SSH to connect to VM(s) that you must set.
The installable version of CircleCI 2.5.0 includes the following fixes and improvements:
This release fixes a problem with DNS resolution failure on alpine-based containers. This problem was observed in the 2.3 release and was fixed for some service containers in 2.4. The 2.5 update fixes the issue for all service containers.
This release includes improvements to scaling and garbage collection in the VM Service that should improve performance for installations with heavy use of machine executors or remote Docker.
The installable version of CircleCI 2.4.0 includes the following improvements and changes:
Audit logging - This feature makes available a downloadable log of system events from the CircleCI Admin dashboard. This is the first release of audit logging; more events and improved data in the logs will be delivered in subsequent releases. Find detailed information about the data fields for each event in the Audit Logging section of the Security Features document.
LDAP integration - It is possible to enable a new CircleCI installation to authenticate users with OpenLDAP or Active Directory credentials. New installations may be configured to have users authenticate through LDAP, including Active Directory support. Refer to the Authentication document for instructions.
New build-agent - The new build-agent fixes some cases in which users were unable to log into a running job with SSH.
VM Service improvements - Autoscaling of the VM Service has been improved, so machine executors should have more consistent performance at scale.
The installable version of CircleCI 2.3.0 includes the following improvements and changes:
Users can now schedule workflows. The underlying cron-service has been added to the installation, though no specific configuration should be needed. See the documentation on Workflows Orchestration for details.
Support for using private IP addresses in 1.0 builds is now enabled along with 2.0 builds
A bug in the VM garbage collector was addressed that should help in situations when VMs were being leaked.
The installable version of CircleCI 2.2.0 includes the following improvements and changes:
New visualization for Workflows - When you click on a workflow in the CircleCI application, a diagram appears with the relationship of your jobs to one another and the complete sequence of the workflow.
Updates to the onboarding flow - We now show a new user only projects already building on CircleCI rather than a list of all projects found in source control. This change was made to prevent inadvertent adding of projects to CircleCI during the onboarding process. We also added a confirmation dialog for any user opting to follow more than six projects and made it clearer how to add new projects not yet building on CircleCI.
Support for object stores other than S3 - CircleCI 2.2.0 now supports the same object store options that are supported in 1.x. This is a prerequisite to future releases that will allow non-AWS installations of CircleCI 2.x.
Updates to the VM Service; ACTION MAY BE REQUIRED IF YOU ARE USING AWS - The VM service has been updated to use volumes rather than persistent instances. This change allows operators to accommodate Docker Layer Caching with a smaller number of long-running VMs. If you installed using the suggested IAM permissions from prior versions you must update your IAM permissions with this upgrade. Refer to the policy template for the complete set of permissions.
New Contexts feature; ACTION MAY BE REQUIRED IF YOU ARE USING THE HIGH AVAILABILITY CONFIGURATION - The Contexts feature uses a HashiCorp Vault secure storage mechanism. If your installation is running in HA mode, HashiCorp Vault needs to be externalized similar to the Mongo and Postgres databases. Refer to the Configuring High Availability documentation for instructions.
CircleCI 2.0 is a completely updated CI/CD platform that starts every run with a clean image which is automatically provisioned just-in-time for Linux jobs on the CircleCI application installed in your private cloud. The CircleCI 2.0 platform includes significant performance, stability, and reliability improvements along with first-class Docker support, Workflows (pipelines), Resource Allocation, and Contexts. The Management Console (Replicated) also includes new options for enabling 2.0 Builders and appropriate default settings.
If you have CircleCI installed you may access CircleCI 2.0 features on your current installation with no restrictions under your current agreement and support level. However, you must contact your CircleCI account representative for assistance with upgrading, to obtain migration scripts, and to receive a new license channel.
CircleCI 2.0.0 is only available on AWS and may be installed with Terraform or manually.
Teams may create a CircleCI 2.0 .circleci/config.yml file in their repositories to add new 2.0 projects incrementally while continuing to build 1.0 projects which use a circle.yml configuration file.
This is a security update to prevent logging temporary access tokens in build output. Those access tokens would have allowed a user to do a PUT request to overwrite an existing artifact only if all of the following were true:
They already had access to the build.
They identified the token in the build output.
The were to use the token within 30 minutes after the original artifact was uploaded.
A minor maintenance release, primarily to improve the single-box installation process for new trials of CircleCI Enterprise. Also, we have now follow advice from GitHub to not check if emails in GitHub Enterprise are “verified” — we will continue to check verified status if you are using github.com. If you have reason to change “verified” checks on your users’ emails let us know.
We have released patches to our AMIs and other infrastructure to address CVE-2016-8655. We recommend all CircleCI Enterprise installations follow the instructions below to update both their Services box and their Builder fleet.
If you have any questions or difficulties please contact email@example.com.
We have released patches to our AMIs and other infrastructure to address CVE-2016-5195. We recommend all CircleCI Enterprise installations follow the instructions below to update both their Services box and their Builder fleet.
If you have any questions or difficulties please contact firstname.lastname@example.org.
Note for Admins: we will now block your upgrade if there are pending migrations that need to be performed against your databases.
We have changed the default behavior for builds with parallelism set above the current total container count in your build fleet. Previously we would auto-cancel any build with a parallelism above the total number of containers in your fleet. Those builds will now remain in the queue until the fleet is big enough to accommodate their parallelism setting. Builds behind those builds will continue to be bumped ahead, however, so the behavior is somewhat different than normal queuing behaviors, which is a strict FIFO model.
New System Settings option to set the maximum parallelism for all projects. This allows you to prevent teams from using more of your fleet than intended.
New option to auto-cancel “redundant” builds on a branch - found in the project settings, this new option allows you to set builds on branches other than your default branch to auto-cancel any builds on that same branch already running. This avoids running multiple simultaneous builds on the same working branch if you push several times in quick succession.
On the Systems Settings page under Admin you can now enter “Container Tweaks” that will be run whenever containers are started in your build fleet. This feature allows you to make adjustments to the build environment prior to builds running, so you can save time in each build. Note that these tweaks are only appropriate for things you want to apply to the environment for ALL of your builds.
We now parse your circle.yml before the build runs and fail if there are errors. Before, the build would start and errors would be surfaced only once they caused a failure in a running build.
Fixed a bug preventing artifacts from being generated in some circumstances after a failed build.
The Artifacts API now allows cross-origin requests when requesting specific artifacts. In the past you could do this when using the API to get a list of your artifacts but not for downloading specific artifacts. You can now do both with the API.
Fixed a bug that prevented some cases of triggering builds via the API. If you have had problems triggering builds with the API you may need to recycle your build fleet for this fix to take effect.
Fixed a bug that would cause problems if someone’s access was removed from a project in GitHub Enterprise but that person’s token was being used by CircleCI Enterprise. Other users should now be able to continue using the project as expected if the original token’s owner no longer has access.
Fixed a bug that prevented builds cancelled from the UI from actually cancelling in a timely fashion.
Various design improvements such as better notifications and confirmation dialogs when changing various settings, new links on the build page and builds list to make it easier to link directly to specific containers or parts of your build output, better information for builds marked as “Not Run”, hiding some settings that aren’t applicable to Enterprise customers, and various minor improvements and bug fixes.
PR-only builds - We have added functionality to only run builds when a pull request is open. To enable this functionality you can navigate to “Advanced Settings” for your project and enable the “Only build pull requests” option.
New Feature: The maximum size of files that you can upload for caching during builds has been fixed to 5G. The size is now bumped 20G by default on CircleCI Enterprise and customers can also override the default value to even larger size.
To override the default value, you need to run the following in a REPL of Service Box.
New Feature: Custom base URL for version control webhooks. When a new project is added, CircleCI will add a webhook to the GitHub repository of the project. With this new feature, you can override the default webhook base URL from the System Settings page under the Admin tools (available to designated administrative users). This feature is useful when your instance is behind firewall or other proxy and cannot directly receive webhooks from GitHub.
This release fixes a bug in the URL structure used to serve build artifacts.
The artifact URL format was recently changed to handle security concerns related to CircleCI’s hosted offering. The security concerns do not affect CircleCI Enterprise customers, but the change caused issues fetching build artifacts in CircleCI Enterprise installations. This release reverts the CircleCI Enterprise artifact format and resolves the issue.
Please Note: If you are using OS X builds you will need to run a manual migration as part of this release. After upgrading you will need to run this in a REPL: (circle.backend.model.esxi-vm/run-migrations!). Please talk with your account manager if you need further instructions.
The Admin Users page now has links to the builds of each user.
The API has a new endpoint /api/v1/admin/licensing that returns information about the number of seats available, number being used, when the license will expire, and how many inactive users there are in the system.
Fixed a bug where links to the documentation broke.
As part of this release we’re changing the behavior of artifacts to
only serve a whitelisted set of content-types. This means we won’t
serve .html files as text/html. This is a security risk on CircleCI
Enterprise since artifacts are served on the same domain as the rest
of the site – as a result, any user or malicious code used as part of
your build can push a specially-crafted artifact and gain control of
another user’s account.
If this is an issue, you can override this behavior by setting
“Serve artifacts with unsafe content-types” in the admin console. We don’t
recommend this, but we’re providing it for backwards compatibility.
This release also includes some changes to container
networking. Containers now each use a /24 in the subnet 172.16.1.0/16
If this conflicts with your private network, or if you were editing lxc-net
manually in order to fix a prior conflict, you can now use
CIRCLE_CONTAINERS_SUBNET and CIRCLE_CONTAINERS_SUBNET_NETMASK_LENGTH
on the builders to configure those. See “Adjusting Builder Networking” in the