New: checksums for the wrapper scripts will now be published for each release and attached to the GitHub release (see 'assets' below)
These checksums can be used to easily verify the integrity of the wrapper scripts used in your project.
For example, these checksums are used by the new
batect-wrapper-validation-actionaction, which validates the integrity of the wrapper scripts as part of a GitHub Actions workflow.
Fixed: downloading update information and updated files and uploading telemetry data (if opted-in) would fail if your system connects to the internet via an encryption-terminating proxy that was not trusted by your Java installation.
These features will now work correctly on macOS and Windows provided your operating system certificate settings are configured to trust the proxy's certificate, which matches the behaviour of browsers and other tools.
⚠️If you use macOS, it's recommended you upgrade to one of the following Java versions to fix a security vulnerability related to this functionality:
- JDK 8: 8u332 or later
- JDK 11: 11.0.15 or later
- JDK 17: 17.0.3 or later
- JDK 18: 18.0.1 or later
- All versions of JDK 19 or later
BuildKit improves the performance of image builds, as well as adding many new features. Not all of BuildKit's features are currently supported by Batect.
Batect's BuildKit support has been in use for many months now and there are no known issues. If you encounter any issues as a result of this change, disable BuildKit by setting the
DOCKER_BUILDKITenvironment variable to
0and report an issue.
Fixed: containers would sometimes be stopped and sometimes be left running if
--no-cleanup-after-failurewas used, depending on how the containers were configured. Now containers will always be stopped.
Fixed: Batect could crash, show an error message or silently use incorrect console dimensions when running on Apple Silicon machines. This could also lead to difficult to read output when text exceeded the width of the console and was not correctly trimmed.
Thank you also to @sschuberth for yet another round of improvements to the build setup for Batect.
- Fixed: the Unix user and group for run as current user mode was not correctly applied to the home directory or any cache directories if they ended with a trailing slash in the configuration file, preventing processes within the container from using these directories
For example, run
./batect --clean-cache=node-modulesto clean the cache named
truein your project to disable telemetry in your project.
Fixed: the schema used for code completion of configuration files in IDEs did not comply with the JSON schema version it claimed to comply with (#1039 - thanks to @ineffyble for reporting and fixing this issue)
Improved: if the background upload of telemetry data fails repeatedly, give up early rather than trying to upload all queued data
I've recently published two RFCs covering significant enhancements to Batect:
The RFC process is intended to allow anyone with an interest in Batect to get involved and help shape it to suit their needs, so please don't be shy! Any comments, suggestions, questions or constructive criticism are more than welcome.
Improved: caches no longer need to be initialised with a separate container and will be no longer have a
.cache-initfile created within them.
This improves performance (as there's no longer a need to start and run another container to prepare caches before they're used), and fixes issues where some applications insist on a completely empty directory, such as Postgres (#1000 - thanks to @ineffyble for the feedback).
--linux-cache-init-imageoption has been removed as it is no longer used.
Note that this change in behaviour does mean that caches using volumes (ie. not using directories with
--cache-type=directory) will now inherit the contents of the target directory from the image when they are created for the first time. Previously, they would always contain only the dummy
.cache-initfile. For example, if a cache is mounted at
/cache, and the image for the container contains files in
/cache, when the cache volume is created for the first time, the contents of
/cachefrom the image will be copied into the volume.
Thank you also to @sschuberth for submitting a number of PRs to improve some of the behind-the-scenes developer tooling.