Overlays

Note

This chapter covers the Buildah based workflow v2.

As soon as a single edi project configuration should support multiple use cases the use of overlays will help to get rid of duplicate configuration code. When using overlays, it is a good practice to put most of the configuration code into a single yaml file. In the edi-pi configuration used throughout the previous chapters this is the file configuration/base/common.yml. A use case like pi5.yml is then just a symbolic link to this configuration file. The differentiation between the use cases happens in the global overlay (e.g. configuration/overlay/pi5.global.yml): edi will initially load the base configuration and then merge it with the global overlay. The configuration done in the global overlay takes precedence over the configuration done in the base configuration.

edi furthermore supports two additional overlays: The configuration can be further tuned per host (the overlay file shall then end with .$(hostname).yml, e.g. .buildd.yml) and per user (the overlay file shall then end with .$(id -un).yml, e.g. .john.yml). The user overlay takes the highest precedence.

The following picture illustrates how yaml configuration files will get merged:

The merged configuration can be displayed using a command like:

edi project make --config pi5.yml

or

edi project make --config pi-cross-dev.yml

The usage of overlays is optional and in any case it is not necessary to specify all possible overlays.

--config

Dump the merged configuration instead of running the command.