CEKit 3.5.0 (and others) released3 min read release
This is a special release day actually. Today we released 3 versions of CEKit. Two bugfixes and one scheduled release. Let me go through these.
CEKit 3.2.1 and 3.3.2 bugfix releases
|These releases are available only on PyPi, there will be no RPMs prepared for these versions.|
To support Middleware teams on the route to continuous development (CI/CD) and not to interrupt their current workflows at thea same time I decided to backport changes from the 3.4.0 codebase into 3.2.x and 3.3.x series.
Usually we would not see it, because CEKit development is linear, we move forward with releases and once a new version is released, support for older releases is very limited and we urge to upgrade to latest released version.
In this case interruptions done by moving to new version could cause delays in product delivery and a decision was made to backport required changes to both 3.2.x and 3.3.x series.
Above releases are exceptions to the general rule.
There are only two features that were backported and both are related to the OSBS builder engine parameters, which make it more flexible.
Support for syncing with dist-git repository without waiting for confirmation (
Support for interrupting the build process after the codebase is synced with dist-git. This means that the code will be available in dist-git, but no build in OSBS would be kicked (
And that’s all, no other changes were made to the CEKit codebase.
The 3.5.0 release contains a few features that
Squashing support for Buildah and Podman
We’ve added support for squashing images in the Podman and Buildah builders. Squashing,
similarly to Docker, is now enabled by default. It can be disabled by using the
Multi-stage builds documentation
Support for multi-stage builds was added in 3.4.0 release, but it was a tech-preview. This time the documentation was added and the multi-stage builds becomes now a regular feature.
Koji target in descriptor
It is possible to define the Koji target directly in the image descriptor. This is useful when the build is executed in a non-standard branch, without the proper configuration.
Improvements in modules handling
Modules that do not have content (for example define only labels or environment variables) will not be added to the image at build time. This means that the build can be executed a little bit faster and resulting image will have less layers.