A new struct in ostree can be used to define configuration options for
the ostree remote of an image. So far remotes were always set up with
the remote URL used to pull the commit. Now we support setting a
different remote with extra configuration options.
This is used by the fedora-iot-raw-image to set up the remote
configuration of the final image, separately from the source of the
commit.
Test manifests updated.
Stages that modify files in the ostree deployment need the sysroot
bindmount for any changes to take effect.
Adding the mount to the keymap and locale stages since they need to
modify files in /etc.
New mount type added: org.osbuild.ostree.deployment.
Adding this to a stage will setup all needed bind mounts so that a given
`tree` will look like an active OSTree deployment, very much as OSTree
does during early boot.
This is often necessary when making changes to files in /etc for an
ostree image.
Adding support for config options to OSTreeDeployment that are required
by the IoT raw image:
- Kernel command line options
- Keyboard layout
- Locale
Test manifests updated.
Include the platform packages when getting the build packages for the
RawOSTreeImage.
rpm-ostree is explicitly added for this image type.
dracut-config-generic and efibootmgr are temporarily added here, but we
should define a platform that includes them instead (some cleanup
required in general).
The map is meant to maintain compatibility with changes in image type
names. Most entries however map to themselves. It's redundant to keep
updating this map with every new image type name and map it to itself.
Instead, check the map for a compat string and if one doesn't exist,
return the original.
Conversely, when the inverse lookup is performed, first check if the
compat string is a valid image type name and only iterate the map if
it's not.
Now we don't need to update the map every time we introduce a new image
type, unless we need to map an old name to a new one.
Add the new image type to the list in each architecture and update
tests.
Ignore ostree raw images in Kernel count test in distro_test_common:
Edge and IoT raw images don't need a kernel specified in their OS
pipeline. The kernel (and the OS in general, including all packages)
come from the commit that is pulled and deployed in the image.
This test passes on RHEL (for edge-raw-image types) because the
blueprint defaults to returning the main kernel, but this isn't
necessary and is likely to change in the near future.
Co-Authored-By: Ondřej Budai <ondrej@budai.cz>
The XZ pipeline is added explicitly for ostree raw images for now.
It should be changed to support compressing general raw images as well.
Co-Authored-By: Ondřej Budai <ondrej@budai.cz>
The RawOSTreeImage pipeline is the OSTree-equivalent to the RawImage.
The serialization is very similar between the two (almost identical),
but the two Pipelines depend on different Tree implementations.
Co-Authored-By: Ondřej Budai <ondrej@budai.cz>
New pipeline for creating an ostree commit deployment.
Heavily based on the ostreeDeployPipeline from RHEL 9.x.
Co-Authored-By: Ondřej Budai <ondrej@budai.cz>
The most interesting change is the removal of smc-meera-fonts in 37. As
suggested, rit-meera-new-fonts is used instead.
Existing F35 and F36 manifests updated with package changes.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
These are just super-simple to construct using a small helper.
It would be great if we can make `distro.go` totally version-agnostic but
that's something for the future.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Distro version branches aren't synced to GitLab, so we will need to
fetch them from GitHub directly.
This is required for any PR made against any branch other than main.
We have recently added testing on aarch64 but not all of the test are
supported on that architecture. Adding specific rules for all and x86_64
arches to simplify which test jobs run on what arches.
We were using `latest` as tag, this can be dangerous as it's the default
tag, an anyone can accidentally update it. Using `prod` is safer.
Also use dev container image if the test script is running in CIV CI.
As it turned out, people make mistakes and forget to write some parts of
code, unless a unit test screams at them. This is true for the
`InheritFrom()` method, which is not handling all members of the
`ImageConfig` structure.
Use reflection, instead of inheriting from each specific hard-coded
structure member. This will make the implementation future-proof in case
the `ImageConfig` structure is extended with additional members.
Using basic types as values in the `ImageConfig` structure makes it
impossible to distinguish if the empty value for the type was set
intentionally or if it is just the value the variable was initialized
to. This is very bad especially for `bool` type.
While working on unifying `vhd` and `azure-rhui` image types I found
out, that some newly added variables in the `ImageConfig` structure
were forgotten in the `InheritFrom()` method. This makes it impossible
to inherit their values from a parent configuration. This is however
required for the unification of `vhd` and `azure-rhui` image types. As
described above, it would be impossible to decide whether a `bool` value
should be inherited from the parent configuration or not. The only
solution is to use a pointer to the type. For consistency, use pointer
for all basic types.
Adjust distro implementations accordingly.
