The image type was added to productmd 1.45, so we should also require
that version.
Merges: https://pagure.io/pungi/pull-request/1841
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
This option can be set for a particular image or globally for all
kiwibuild images (with individual overload).
Fixes: https://pagure.io/pungi/issue/1833
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
If we happen to have a symlink to an RPM that should be linked into the
compose, we should first resolve it to the actual path. This avoids a
problem if the symlink is relative, as otherwise Pungi would copy/link
the actual relative symlink, which would break it in the new location.
If the path is not a symlink, resolving the real path should make no
difference.
JIRA: RHELCMP-14504
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
This patch adds support for Opentelemetry. If
OTEL_EXPORTER_OTLP_ENDPOINT env variable is defined, it will send traces
there. Otherwise there is no change.
The whole compose is wrapped in a single span. Nested under that are
spans for operations that involve a remote server.
* Talking to CTS
* Sending API requests to Koji
* Any git repo clone
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
When container-images are downloaded, they would be skipped from the
extra_files.json manifest. This patch fixes that by enumerating all
files rather than relying on the getter to return a list.
JIRA: RHELCMP-14406
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
The getter is already running once per architecture, it just doesn't
make the information available to the scm wrapper.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
All these are calling subprocess in 'text mode', where it will
try to decode stdout/stderr using the default encoding (utf-8
for us). If it doesn't decode, subprocess will raise an exception
and kobo doesn't handle it, it just passes it along to us, so
things blow up - see https://pagure.io/releng/issue/12474 . To
avoid this, let's set `errors="replace"`, which tells the decoder
to replace invalid data with ? characters. This way we should get
as much of the output as can be read, and no crashes.
We also replace `universal_newlines=True` with `text=True` as
the latter is shorter, clearer, and what Python 3 subprocess
wants us to use, it considers `universal_newlines` to just be
a backwards-compatibility thing - "The universal_newlines argument
is equivalent to text and is provided for backwards compatibility"
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Merges: https://pagure.io/pungi/pull-request/1812
This could be useful for handling flatpak applications in the installer.
All of the specified containers are downloaded into a single oci
layout.
JIRA: RHELCMP-14302
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
In https://github.com/release-engineering/productmd/pull/181 I
added new `bootable-container` and `container` types to
productmd. This makes pungi always use the bootable-container
type for ostree_container images (previously 'ociarchive'), and
default to using the container type for Kiwi-built oci.tar.xz
container images (previously 'docker').
This is a significant change for anything that relies on
productmd/fedfind conventions to 'identify' images, as these
images will now have a different identity. But I think it's a
valuable improvement in their identities. 'ociarchive' never made
any sense as an image 'type' - it's a format - and 'docker'
wasn't a very good type for images that are explicitly OCI
container images, not Docker-native ones. We also can now easily
distinguish between 'regular' container images and ones that are
intended to be bootable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The pkgset phase takes around 35 minutes in current composes.
Around 20 minutes of that is spent creating these per-arch
subsets of the global package set. In a rather roundabout way
(see #1794 ), I figured out that almost all of this time is
spent in this cache check, which is broken for a subtle reason.
Python's `in` keyword works by first attempting to call the
container's magic `__contains__` method. If the container does
not implement `__contains__`, it falls back to iteration - it
tries to iterate over the container until it either hits what
it's looking for, or runs out. (If the container implements
neither, you get an error).
The FileCache instance's `file_cache` is a plain Python dict.
dicts have a very efficient `__contains__` implementation, so
doing `foo in (somedict)` is basically always very fast no matter
how huge the dict is. FileCache itself, though, implements
`__iter__` by returning an iterator over the `file_cache` dict's
keys, but it does *not* implement `__contains__`. So when we do
`foo in self.file_cache`, Python has to iterate over every key
in the dict until it hits foo or runs out. This is massively
slower than `foo in self.file_cache.file_cache`, which uses the
efficient `__contains__` method.
Because these package sets are so huge, and we're looping over
*one* huge set and checking each package from it against the cache
of another, increasingly huge, set, this effect becomes massive.
To make it even worse, I ran a few tests where I added a debug log
if we ever hit the cache, and it looks like we never actually do -
so every check has to iterate through the entire dict.
We could probably remove this entirely, but changing it to check
the dict instead of the FileCache instance makes it just about as
fast as taking it out, so I figured let's go with that in case
there's some unusual scenario in which the cache does work here.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The default base name is probably fine in most cases, but there
are some where we might want to tweak it. We already allow this
for other phases (e.g. the livemedia phase).
Also, we should include the arch in the image filename. Not doing
this doesn't blow up the compose as, while they have identical
filenames, the images for different arches are in different paths,
but it's confusing for people who actually download and use the
images.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The image metadata construction code allows for subvariant to be
set in the image config dict, but checks.py doesn't expect it;
fix that. Also, when a subvariant is set, use it in the image
name template rather than the variant; otherwise you can't
build more than one subvariant in any variant (they will have
identical names, which isn't alllowed).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
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>
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>
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>
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>
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>
Running xorriso to modify an ISO image can update content of included
images such as images/eltorito.img, unless we explicitly update the
image, which is undesirable (https://pagure.io/pungi/issue/1647).
However, when the file is changed, the checksum changes and .treeinfo no
longer matches.
This patch implements a workaround: once the DVD is written, it looks
for incorrect checksums, recalculates them and updates the .treeinfo on
the DVD. Since only the checksum is changing and the size of the file
remains the same, this seems to help fix the issue.
An additional step for implanting MD5 is needed again, as that gets
erased by the workaround.
JIRA: RHELCMP-13664
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
This phase was used to create live images with livecd-creator
and 32-bit ARM images with appliance-creator. We also remove
get_create_image_cmd from the Koji wrapper as it was only used
for this phase, remove associated tests, and remove related
configuration settings and documentation.
Fixes: https://pagure.io/pungi/issue/1753
Merges: https://pagure.io/pungi/pull-request/1774
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When variant X depends on variant A, Pungi creates a temporary local
lookaside with packages from A. If there's an external lookaside
configured, the list of package for variant A can contain URLs to the
external repo.
Newer versions of createrepo fail when pkglist specifies an unreachable
package, and it doesn't do downloading.
JIRA: RHELCMP-13648
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
If a module is not built for specific arches, pungi will skip adding it
to these arches in pkgset phase.
JIRA: RHELCMP-13625
Signed-off-by: Haibo Lin <hlin@redhat.com>
Pungi can use either genisoimage or xorriso to create ISOs.
It also needed isoinfo utility for querying volume ID from the ISO
image. However, the utility is part of the genisoimage suite of tools.
On systems that no longer provide genisoimage, the image would be
successfully generate with xorriso, but then pungi would fail to extract
the volume id leading to metadata with missing values.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
The ostree and ostree_container phases both log messages in the
exact same form, which is rather confusing. This will make it
much clearer which message comes from which phase.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
composetracker expects the failure message to be in a specific
form, but some phases weren't using it. They were phrasing it
slightly differently, which throws off composetracker's parsing.
We could extend composetracker to handle both forms, but it seems
simpler to just make all the phases use a consistent form.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
As discussed in
https://pagure.io/releng/failed-composes/issue/6047#comment-899622
the list of 'acceptable' types and formats (in productmd terms)
is locked down in productmd, we cannot just 'declare' new formats
in pungi as we kinda wound up doing by adding these Kiwi
extensions to the EXTENSIONS dict in image_build phase. So
instead, let's return the image_build phase to the way it was,
and add an additional layer of handling in kiwibuild phase for
these awkward cases, which 'translates' the file suffix to a
format productmd knows about already. This is actually how we
would rather behave anyway, because a Kiwi-produced
`vagrant.libvirt.box` file really is the same kind of thing as an
ImageFactory-produced `vagrant-libvirt.box` file; we want them to
have compatible metadata, we don't want them to look like
different things.
Merges: https://pagure.io/pungi/pull-request/1740
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Neal wanted this to work - he tried using global_description_scm
and global_description_path in the initial PR - but it wasn't
wired up to work. This should make it possible to set
`kiwibuild_description_scm` and `kiwibuild_description_path`.
It also technically lets you set `global_` for both, since the
`get_config` implementation is very generic, but it doesn't add
it to the checks, so you'd still get an "unrecognized config
option" warning, I think. It seems appropriate to encourage
setting this as a phase-level option rather than a global one
since it seems quite specific to the kiwibuild phase.
Merges: https://pagure.io/pungi/pull-request/1737
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The mechanisms here are a bit subtle and the kiwibuild phase
didn't quite get them right. The arg passed to `util.failable`
is supposed to be a boolean, but kiwibuild was passing it the
list of failable arches (which will always evaluate True).
How this is meant to work is that we only make *the Koji task
as a whole* failable (by passing `True` to `util.failable`) if
*all* the arches in it are failable. If *any* arch in the task
is not failable, the task should not be failable.
We allow a subset of arches to fail by passing the Koji task a
list of `optional_arches`, later. If an arch is 'optional', that
arch failing won't cause the Koji task itself to be considered
failed.
This commit fixes the logic (I hope), renames all the variables
and adds a couple of comments to make it clearer what's going on,
and does a bit of making the code simpler.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Kiwi builds for Azure fixed VHD images are suffixed with "vhdfixed"
instead of plain "vhd". Add that to the list of suffixes.
Signed-off-by: Jeremy Cline <jeremycline@microsoft.com>
According to Neal, Vagrant images produced by Kiwi end in e.g.
`vagrant.libvirt.box` and `vagrant.virtualbox.box` - with a
period between `vagrant` and the image type, not a dash as with
oz. We should accept this slightly different format so we can
correctly derive the productmd `type` and `format` for these.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The osbuild Koji plugin supports passing customizations for an image
build. This is also supported in the Koji CLI plugin. Some teams want to
pass image customizations for images built as part of Pungi composes.
Extend the osbuild phase to support passing customizations in the Pungi
configuration.
Merges: https://pagure.io/pungi/pull-request/1733
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The plugin supports two modes of operation:
1. Mount a shared storage volume into the runroot and have the output
written there.
2. Have the plugin create a tar.gz with the outputs and upload them to
the hub, from where they can be downloaded.
This patch switches from option 1 to option 2.
This requires all input repositories to be passes in as URLs and not
paths. Once the task finishes, Pungi will download the output archives
and unpack them into the expected locations.
JIRA: RHELCMP-13284
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
