Dependabot pushes branches directly to the upstream repository. This causes
double-triggers of gitlab CI. Prevent it by running gitlab CI only for
the main branch.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
The 'google-cloud-sdk' RPM built by Google for RHEL, which provides
the 'gcloud' command, is built only with Python 2. Since Python 2.7
is already EOL in upstream and not available in CentOS Stream 9, we
can not use 'gcloud' from the 'google-cloud-sdk' RPM.
The 'awscli' is not available in RHEL-9 repositories.
The Azure CLI 'az' available in official upstream repositories has
broken dependencies on RHEL-9 and can not be successfully installed. To
workaround the issue, run the tool from the official container image
provided by Microsoft.
Use the `quay.io/osbuild/cloud-tools` F34-based container image instead
of locally installed cloud CLI tools.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The RHEL-8.5 and RHEL-9.0 `ami` images are now based on the official
RHEL EC2 images. As a result, they use a different default user -
`ec2-user`.
Fix the `api.sh` test case to use the correct user when testing RHEL-9
`ami` images.
Fix#1632
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Move the ostree repository and the tar image to the root of the
boot iso. This has several advantages: we do no longer have to
correctly guess the size of the anaconda image. Also we do not
need to compress the payload within the squashfs.
Update the image installer's test data. NB: the changes to the
package list were introduced earlier and should mostly affect
the build pipeline. Should have caught is in the corresponding
change, but was apparently not picked up by CI.
Release osbuild-composer 32
Signed-off-by: Simon Steinbeiss <simon.steinbeiss@redhat.com>
Co-Developed-by: Christian Kellner <christian@kellner.me>
Co-Developed-by: Tom Gundersen <teg@jklm.no>
OSBuild Composer can now build the RHEL 8.5 Raw Images. This images are
compressed raw images, i.e. a file that has a partition layout with an
deployed OSTree commit in it. It can be used to flash onto a hard drive
or booted in a virtual machine. An existing OSTree commit needs to
be provided.
The following image new types are supported: edge-raw-image.
Instead of using package sets at the distro, arch and image type
level and then merging them in `PackageSets`, store the function
that generates the package set in the image type and have them
return all the package set. In order to do so, they now take an
imageType parameter so that they can also return architecture
dependent packages.
Instead of having a common build package set defined at distro
struct level and merging them together with build packages in
the image type (and arches), we do the "inheritance" at the
package set level and append more specific packages to base
sets there. We also now ensure that each image type does have
a build package set defined.
The actual package set should not change for anything due to
this commit.
Split the common installer build packages from the one specific to
anaconda and edge.
NB: The "inheritance" is now done in the package sets rather than
outside, via package set merging.
The edge specific build packages, `edgeBuildPkgsKey` where defined
on the distro level but also always included in all actual edge
image types; there were thus duplicated.
This adds a new installer called the "Simplified Installer" for Edge.
In contrast to the existing insaller, which is based on Anaconda, this
new installer based on the CoreOS installer project[1], a small rust
based binary that is executed in the initramfs and will flash a raw
image to a specified installation device. For this a new blueprint
option is introduced. The raw image is created from an existing OSTree
commit and embedded into the resulting bootable iso. When booting the
iso the installation will automatically start witout any interaction
from the user.
NB: As with the existing edge installer, support is currently limited
to x86. The new installer also does not support non-uefi boot.
[1] https://github.com/coreos/coreos-installer
Co-Developed-by: Achilleas Koutsou <achilleas@koutsou.net>
Co-Developed-by: Antonio Murdaca <runcom@linux.com>
Add a new param to the helper function creating the grub2 stage, that
indicates whether greenboot should be enabled. So far this is false
for all uses, so nothing should change.
