Make the v1StageResult.Metadata a simple json.RawMessage and perform the
RawMessage to StageMetadata conversion in the convertStage functions.
This lets us get rid of the custom v1StageResult Unmarshaller and the
v1RawStageResult, and makes the whole conversion process easier to
trace.
Types, parsing functions and helpers copied from osbuild1 to
osbuild2/v1result.go.
The metadata handling is simplified: osbuild1 stage metadata for the RPM
and ostree-commit stages is identical to the osbuild2 counterparts.
The test_distro Manifest, which is used in tests across multiple
packages, was using the old structure. Updated to the v2 structure and
adapted all tests.
There appears to be a problem with nested virtualization on newly added
hypervisors with ssd. I believe the issue is not preset on regular
instances, so switching to those until the issues can be resolved.
This introduces an expiry date (default: 14 days from insert date) and
adjust the service-maintenance script to delete jobs that are older than
the expiration date.
While this feature is 'not mature yet' according to Packit developers,
we can enable it because there's no harm done. If Packit fails to
publish the Bodhi update then fedora-bot will take care of it.
We have three kinds of operating system trees, until we unify them to one,
hide them behind one interface. Use this to read the architecture from the
Tree rather than pass it in as a string to parent pipelines.
Also, make the filename parameter optional in a few places, there should be no
reason to set this rather than introspect it (except for backwards
compatibility).
Lastly, add another playground example sample to build a raw image.
For now all it does is represent the name of the runner and what requirements
it has of the build pipeline.
Move some package definitions from the runner package set to where it belongs.
With the more fine-grained build package set, different images will use
different build pipelines and each of them will be smaller.
We don't currently cache build pipelines so there is no downside to this. Even
when we start caching the difference between having one build pipeline per
image and one shared one is minimal at scale. This will still benefit users
doing one-off builds on-prem.
Most importantly, this tracks things correctly, making pipelines more
composable without having to maintain a global list of dependencies.
This should have no practical effect, but ldconfig is used from
runners, so it is strictly speaking a requirement.
At the same time document the remaining TODO's in the build
pipeline.
The build pipeline requires the selinux packages only if we are going to be
labelling the files in the target OS. Otherwise, skip it.
manifest/build: pull in selinux-targeted unconditionally
This is unconditionally used by the build pipeline itself, until we make that
conditional, it needs to be installed.
We stopped testing on RHEL 8.4 because it wasn't changing, but now it
will be (or might) since it lives inside the common rhel8 package.
Testing the distro ensures we don't break it. RHEL 8.4 is still
supported as EUS.
We will soon change the distro definition to specifically build 8.4 EUS.
Pin osbuild version for RHEL 8.4.
Change the ostree test to support 8.4 (and not 8.5).
Manifest diffs can sometimes get large and putting them in the log makes
life harder for everyone.
Save them in a single file in the job artifacts instead.
Update the comment left by Schutzbot on the PR to mention the artifacts.
edge-raw and edge-simplified-installer: only on 8.6+
ec2 and ec2-ha: available on all RHEL 8
ec2-sap: available on 8.4 and 8.6+ (no 8.5)
The ec2-sap image requires ansible, which in 8.4 is called `ansible` and
was replaced by `ansible-core` in 8.6.
Added unversioned (el8, no minor version) repositories for RHEL 8.4
that provide packages for building ec2 and azure-rhui image types.
Added new repo snapshots to RHEL 8.4: ha, sap, and saphana
With the merging of 8.4 into the main rhel8 package, the name
'rhel-edge-commit' is no longer the primary name for the image type.
More generally, the 'rhel-' prefix doesn't appear in the main name for
any image type anymore.
Converted by loading them through the manifest parser in osbuild and
formatting them through v2 before dumping.
These are not the "real" manifests that osbuild-composer would generate,
but they will make it a tiny bit easier to compare and detect changes in
the distro definition when it's moved to the common rhel8 package.
This represents how our systems should integrate into their environment, typically using
some sort of agent, or commonly cloud-init.
In the future we could imagine this representing network configuration or any other kind
of configuration necessary to reach the environment as well.
For now EC2 and Azure is supported, and stub environments are
added to show the idea, but these are not implemented/used
yet.
The workload encapsulates what the user wants to run on top of the image. Everything
else we do abstracts away the OS, the hardware, the environment, and what is left is what
matters: the workload.
For now only the `Custom` payload is implemented which requires the user to name the
packages they want installed, the repositories to pull them from and what systemd
services to enable.
A few other stub workloads are added to show the idea, but these are not used.
The ideal is for the workload to have only the minimal number of configuration options.
Always include the tools for all the filesystem types in the partition table. There may be
usecases for having additional ones, for instance if the partition table is not known, but
this gives us a minimal baseline.
This includes dosfstools in images that have a vfat partition but did not include the tools.
Any package that is added by the pipeline definition should be in the base package set
and the user package set should only be for packages explicitly added by the user.
Any combination of implicitly added packages should depsolve, or it is a bug. However,
user provided packages can have conflicts which must be handled gracefully.
This change is not breaking, as that would be a bug (per the above) and it makes our
behaviour more predictable as any conflicts are caused by explicitly added packages.
Note that this changes the logic from the kernel package being depsolved twice to only
being depsolved in the base package set.
Pass PackageSets when initialising the Manifest, and read the chains back out.
This also fixes a bug where all repos were always used, rather than filtering per
package set.
Finally, this moves the 'chrony' inclusion from distro.go to the OSPipeline where
it belongs. In doing so the logic is changed slightly, where chrony is now
installed if NTP servers are configured (regardless of source), whereas in the
past it was included if the timezone was set in the blueprint (which made no sense).
