Koji's image-build command has not been capable of producing a
docker image with .tar.gz as its extension since 2015:
https://pagure.io/koji/c/b489f282bee7a008108534404dd2e78efb2256e7?branch=master
as that commit message implies, the files have not actually been
gzip-compressed for even longer:
https://pagure.io/koji/c/82a405c7943192e3bba3340efe7a8d07a0e26b70?branch=master
so there's no point to having this any more. It is causing the
wrong productmd 'type' to be set for GCE cloud images, which *do*
have the .tar.gz extension - because docker appears in this dict
before tar-gz, their type is being set as 'docker' not 'tar-gz'.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
(cherry picked from commit 739062ed3c471e74ba9c5144c4047f67f9fbe8c8)
The image-build phase's EXTENSIONS dict is meant to exactly
mirror the 'formats' that exist in the context of the command
`koji image-build`, which is driven by this phase. That nice
association was lost, however, by adding a couple of items to it
which exist for the purposes of the osbuild phase (and in the
case of .iso, also the kiwibuild phase), which import this dict
and uses it for image identification.
To make the association 1:1 again and more clearly show what's
going on here, let's move those entries out into the osbuild and
kiwi phases. osbuild now has its own dict which starts out as a
copy of the image-build one before being extended. And let's
update the relevant comments.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
(cherry picked from commit 5338d3098ccd614a8fd32f837a393aed78b471bd)
The bug that caused the attribute to have wrong value has been fixed in
DNF a long time ago.
Fixes: https://pagure.io/pungi/issue/1786
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
(cherry picked from commit 225f04cf43326c136e95356681f1461270673ca6)
It is not possible to reliably detect what the type for an image should
be in the metadata. This commit adds an option for user to explicitly
provide it.
It can only be configured on the specific image, not globally.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
(cherry picked from commit cd2ae81e3c63316997b9617ff2e30e3148af14f2)
When Kiwi builds an ISO, it is always supposed to be bootable and should
be located in the iso/ subdirectory.
Any other kind of image should still land in images/ and be listed as
not bootable in the metadata.
Relates: https://pagure.io/pungi-fedora/issue/1342
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
(cherry picked from commit d9d21d3cf4eaad5cc7f2959a4abdafed781bb9cf)
The version follows the same rules as versioning for live media etc.
That means it's always going to be set. The precedence goes like this:
* image specific option
* `kiwibuild_version`
* `global_version`
* `release_version` or `<release_version>_<label_milestone>`.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
(cherry picked from commit d351773dab7b3aa8e6de82bbe23058b6b3448dd4)
PR #1789 improved various aspects of the ostree_container phase
regarding subvariant handling and filenames, this is mainly to
help us with how we want to handle bootc images (currently in
the IoT compose, but the generic base bootc image may move to
the Fedora compose).
PR #1790 rejigs the compose phase handling so the main image
build phase is not unnecessarily blocked on the ostree_install
phase. This should cut 60-90 minutes out of the main Fedora
compose time.
(cherry picked from commit 13884fef2c199b613442af03c24b737a7e3cb057)
We can have a compose with unsigned packages.
By the time the next compose is generated, the packages could have been
signed. However, the new compose would still reuse the ISO with unsigned
copies.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
(cherry picked from commit d546a49299)
Without this fix existing configurations break even though they don't
use the phase.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
(cherry picked from commit c59f2371a3)
