This is necessary for the new simplified release process and is done
ahead of time once for the upcoming release now.
After osbuild 40 this will be done by the GitHub composite action.
This commit changes our release process from the model of having a
release commit (and pull request) which also updated the NEWS.md file
and bumped the versions in the osbuild.spec and setup.py files to simply
pushing a tag.
After the tag (containing the release notes) is pushed, a GitHub
composite action is triggered that creates a GitHub release with the
contents of the git release tag. Furthermore the bumping of the version
number now always has to happen directly after a release to avoid having
to push a(n untested) commit to main for the release and this is also
handled by the GitHub composite action.
Finally packit pushes directly to dist-git now on pushing the release
tag, so no pull-request needs to be reviewed and merged anymore.
rpmbuild actually complains about it:
*** WARNING: ./usr/share/osbuild/schemas/osbuild1.json is executable but has no shebang, removing executable bit
*** WARNING: ./usr/share/osbuild/schemas/osbuild2.json is executable but has no shebang, removing executable bit
When new ostree related stages and the new ostree input was added
they were included in the main package since all the modules were
manually listed in the corresponding exclude/include sections.
Change that by using wildcards, since all ostree related modules
should start with the org.osbuild.ostree* pattern.
We do want to turn the dependency generator off for runners,
because they are tied to the specific platform, which might, if
not disabled, introduce dependencies for that platform to the
general package. An prominent example is platform-python used
by the RHEL runner.
On the other hand, we do want to pick up the dependency for the
stages and assemblers, i.e. /usr/bin/python3, because they need
to be able to run on the host, since the host provides the root
file-system for the initial build container, the build host.
Add an additional comment to the shebang mangling exception to
explain that due to the combination of dependency generator and
the disabling of shebang mangler for assembler and stages an
additionally dependency on /usr/bin/python3 will be added on RHEL,
and that this is what we indeed want.
Stop the rpm post install script from mangling shebangs for runners,
stages, and assemblers on RHEL. This breaks running them in osbuild
build roots, which might contain a different operating system than the
host, and thus not have platform-python.
This was always the intended behavior, and cb265e8b5 was a step in that
direction.
In effect, this changes a requirement on build roots, because when
building RHEL on RHEL, all current stages and assemblers now have a
python3 shebang. Thus, this means all build roots must have python3
explicitly installed.
Fixes#354
This swaps the `systemd-nspawn` implementation for `bubblewrap` to
contain sub-processes. It also adjusts the `BuildRoot` implementation
to reduce the number of mounts required to keep locally.
This has the following advantages:
* We know exactly how the build-root looks like. Only the bits and
pieces we select will end up in the build-root. We can let RPM
authors know what environment their post-install scripts need to
run in, and we can reliably test this.
* We no longer need any D-Bus access or access to other PID1
facilities. Bubblewrap allows us to execute from any environment,
including containers and sandboxes.
* Bubblewrap setup is significantly faster than nspawn. This is a
minor point though, since nspawn is still fast enough compared to
the operations we perform in the container.
* Bubblewrap does not require root.
At the same time, we have a bunch of downsides which might increase the
workload in the future:
* We now control the build-root, which also means we have to make sure
it works on all our supported architectures, all quirks are
included, and all required resources are accessible from within the
build-root.
The good thing here is that we have lots of previous-art we can
follow, and all the other ones just play whack-a-mole, so we can
join that fun.
The `bubblewrap` project is used by podman and flatpak, it is packaged
for all major distributions, and looks like a stable dependency.
A usual step in creating OS file system trees is to apply the
correct SELinux labels for all files and directories. This is
done by the org.osbuild.selinux stage, which internally uses the
setfiles command in order to do so. The SELiunx policy to be
used for this operation is the one of the newly created system,
not the host one. It therefore can contain labels that are not
known on the host. The kernel will prevent setting invalid,
i.e. unknown, labels unless the caller has the CAP_MAC_ADMIN
capability. By default, setfiles is executed in the setfiles_t
domain, where it lacks that capability. Therefore a custom
osbuild SELinux policy was created, with a special transition
rule that will execute setfiles in the setfiles_mac_t
domain. All stages, sources and assemblers as well as the main
binary are label with the new osbuild_exec_t label.
Additionally, allow a transition from osbuild_t to install_t by
using `anaconda_domtrans_install`, so that ostree and
rpm-ostree, which are labeled as install_exec_t, can transition
to the install_t domain when called form osbuild. Update the
spec file to build the policy and include it in a new
osbuild-selinux sub-package.
Major changes are the support for ignition, that assembler results
wont be automatically committed anymore, a new org.osbuild.copy
stage, the removal of the `tree_id` & `output_id` as well as full
manifest validation due to the addition of source schema validation.
Now that as a result of commit 4d2f15f all symlinks have been
dropped from the individual module paths, the search for module
contents can be simplified again.
Install the schema to %{_datadir}/osbuild/schema and provide a
link from %{pkgdir}/schema to that location so that the osbuild
library can easily access the schemata.
Drop the `osbuild -> ../osbuild` symlink from all module directories.
We now properly initialize the PYTHONPATH to provide the imported
osbuild module from the host environment. Therefore, these links are no
longer needed.
The sources run from the host environment, so they should just pick them
up from the environment the same way osbuild itself does.
We want to run stages and other scripts inside of the nspawn containers
we use to build pipelines. Since our pipelines are meant to be
self-contained, this should imply that the build-root must have osbuild
installed. However, this has not been the case so far for several
reasons including:
1. OSBuild is not packaged for all the build-roots we want to support
and thus we have the chicken-and-egg problem.
2. During testing and development, we want to support using a local
`libdir`.
3. We already provide an API to the container. Importing scripts from
the outside just makes this API bigger, but does not change the
fact that build-roots are not self-contained. Same is true for the
running kernel, and probably much more..
With all this in mind, our strategy probably still is to eventually
package osbuild for the build-root. This would significantly reduce our
API exposure, points-of-failure, and host-reliance. However, this switch
might still be some weeks out.
With this in mind, though, we can expect the ideal setup to have a full
osbuild available in the build-root. Hence, any script we import so far
should be able to access the entire `libdir`. This commit unifies the
libdir handling by installing the symlinks into `libdir` and providing
a single bind-mount of the module-path into `libdir`.
We can always decide to scratch that in the future when we scratch the
libdir-import from the host-root. Until then, I believe this commit
nicely unifies the way we import the module both in a local checkout as
well as in the container.
