We are excited to announce the release of Rugpi version 0.6. 🎉
This release introduces significant enhancements to the image building pipeline, elevating its flexibility and power.
⚠️ With version 0.6 we introduced backwards-incompatible changes to the image building pipeline.
Continue reading for details on the changes and a smooth upgrade process.
What's new?
Version 0.6 comes with an overhauled and more powerful image building pipeline.
In addition, it makes it much easier to share recipes with the community via Rugpi repositories.
(1) Layers. With version 0.6, we introduce the concept of layers.
Unlike previous versions of Rugpi, where customizations were limited to a single set of recipes, you can now create multiple layers, each with its own set of recipes and parameters.
Layers offer more flexibility.
For example, if you are working on different variants of a product, you can define a layer for each variant.
Layers can also be build on top of each other, allowing you to establish a base layer and then create additional variants on top of it.
Layers are cached and only rebuild if there are changes to their recipes, parameters, or parent layers.
(2) Explicit Recipes Enabling. We have made a shift from recipes enabled by default to a more explicit approach.
Recipes now always need to be explicitly enabled, providing greater control over the applied customizations.
In particular, this means that modifications specific to Raspberry Pi will no longer be applied automatically.
Instead, you now need to explicitly enable them via the core/raspberrypi recipe.
In the future, this will allow us to support other boards than Raspberry Pi.
(3) Repositories. It was an explicit goal from the beginning to facilitate the sharing of recipes within the community.
With version 0.6, we introduce repositories, making it much easier to share recipes and layers.
Repositories can be local directories, e.g., managed with Git submodules, or remote Git repositories.
They can be included with a single line in your Rugpi Bakery configuration.
For example:
[repositories]
rugpi-extra = { git = "https://github.com/silitics/rugpi-extra.git", branch = "v0.6" }
Repositories also provide a namespace for recipes thereby avoiding conflicts.
For instance, the zsh recipe from the rugpi-extra repository is referred to by rugpi-extra/zsh.
(4) Multiple Images. It is now possible to define multiple images.
As a result, you can now easily build images for different boards which require different boot flows or architectures.
Furthermore, different images can be based on different layers, providing even more flexibility.
(4) Simplified Building Process. Building an image is now a one-liner:
./run-bakery bake image <image-name> build/<image-name>.img
This will download the required base image, apply all customizations as defined by the layers, and finally assemble the image, which is then ready to be flashed or installed.
Upgrading to v0.6
Excited about the new features? 🚀 Upgrading to version 0.6 is easy:
- Replace your
run-bakery script with the latest version found in the template.
- Create a layer configuration using
core/raspios-bookworm (for Raspberry Pi OS Bookworm) as parent layer and move the set of enabled recipes and their parameters there.
- Adapt the set of enabled recipes and their parameters. To this end, you need to prefix the recipes previously provided by Rugpi with
core/, enable the core/raspberrypi recipe to get back the Raspberry Pi-specific modifications, add the rugpi-extra repository in case you are using any of the recipes which have been moved there, adjust the recipe names in the parameters section accordingly, and explicitly add local recipes you want to enable.
- Move the image configuration into a respective
images section.
Check out the new template for an example.
What's next?
With the overhauled image building pipeline and layer system, we are now in a position to add support for other boards and fail-safe delta updates.
We also aim to improve the command line interface and the Rugpi Admin web interface.
Finally, another focus will be on reproducibility, compliance, and provenance tracking of the software components integrated into an image.
Got ideas or suggestions? Please open a discussion or issue on Github.
