The createiso and buildinstall phases use this flag to switch which
backend is used. I've added this to the other stages that produce ISOs
thought we might want to discuss the naming?
Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
The image-builder and kiwi phases did not implement the ISO-specific
bits to store additional metadata (`implant_md5` and `volume_id`).
This commit adds those inspections and sets the appropriate fields on
the image object so these values show up in `images.json`.
Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
When failable=['*'] is configured, the arch list was expanded using
image_conf['arches'], which raises a KeyError when 'arches' is not
explicitly set in the config. Use build_arches instead, which is already
computed as the intersection of configured and available arches and is
always present.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
The main improvement here is to write Koji task IDs, where
possible, into the JSON file which records required, attempted
and failed deliverables in the compose.
This actually writes a deliverables-v2.json in a new format
alongside a deliverables.json in the original format, in case
anyone was relying on that format. In the new format, if we are
able to know the Koji task ID associated with the deliverable,
we include it (otherwise it's None / null).
This requires a bit of new plumbing to allow phase workers to
log the task ID once they've found it, because we never have it
when we call `failable`, which is the usual entry point to this
logging. We add a new `record_deliverable_kojitask` method which
workers can use to log the Koji task ID in a dict keyed on the
"deliverable" and the "num", which *ought* to always be unique.
It also means we need to add `num` to the signature of `failable`
so we have it available at all the points we need it.
Then at the end of the compose process, when we do the logging
work with the dicts of required / failed / attempted deliverables,
we map the Koji task dict into the data before logging and
outputting it.
Along the way, we do some rationalizing of when we're using the
concept called "deliverable" in the phases instead of repeating
magic strings which are hard to distinguish from sometimes-but-
not-always-identical concepts like the "phase name".
We also improve Koji task ID discovery for some Runroot-based
phases. Runroot can run a command in Koji, ssh, or locally. The
`run` method previously always returned `None` (implicitly); we
change it to return a Koji task ID if whatever sub-runner it used
returned one, which will be the case if it was the Koji runner.
This allows phases that use Runroot to get a Koji task ID if
possible, record it for this mechanism, and also log it in their
DONE message.
Finally, we also log the Koji task ID in the [FAIL] message
logged in `util.log_failed_task` if possible.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We dropped the "buildinstall" (as opposed to "lorax") method for
this phase in b513c8cd00 in 2023,
but these codepaths were left. They cannot be reached any more
because variant was only None when using the "buildinstall"
method, with the "lorax" method it is always set.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The failable arches from the configuration were always overwritten with
an empty list.
In today's rawhide compose we noticed an image built with
`image-builder` that was set to `failable=['*']` actually doomed a
compose. Let's fix that.
Note that this is a partial fix; the case where a single arch is
failable is not handled here yet but we currently do not have any
configs anywhere that have a partially failable deliverable for
`image-builder`.
Since the latter case (partial failable) needs to pass the argument
along to the koji plugin I'll need to update the plugins schema first to
accept the argument, hence I'll do that in a follow-up.
Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Previously, the test phase performed sanity checks on all images after
the entire compose was created. This meant errors were detected late and
in a context removed from the phase that created the problematic image.
This commit moves image sanity checks directly into the phases that
generate images, providing immediate feedback when an image is created.
Image format and bootability validation:
- createiso: validates DVD/ISO images after creation
- extra_isos: validates extra/unified ISO images
- buildinstall: validates boot.iso
- livemedia: validates live media ISOs
- ostree_installer: validates OSTree installer ISOs
- kiwibuild/imagebuilder/osbuild: validates bootable ISOs
The test phase now only validates image metadata serialization.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
We're pretty sure these are now obsolete. Fedora definitely does
not use them and I cannot find any indication that any currently-
active CentOS or RHEL compose uses them.
We also update tests and docs, remove some things in compose that
were only used by these phases, and - since we're touching
phases.rst anyway - clean up stray mention of another phase that
was removed a while back (LiveImages).
Merges: https://pagure.io/pungi/pull-request/1904
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This code is not really used anymore as users either stop needing this
or implemented their own check that handles additional use cases.
Let's simplify the code base by removing unneeded parts. The old
configuration options are still accepted, but only report a deprecation
warning.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
The `rpm_repo_mapping` config option previously only accepted a single
string URL. This change allows it to accept a list of URLs, expanding
each into separate numbered repo entries (rpm-repo-mapping-0,
rpm-repo-mapping-1, ...) when writing the pungi config.
Update the schema in checks.py to allow either a string or list of
strings for the repos values.
JIRA: RHELCMP-15220
Signed-off-by: Haibo Lin <hlin@redhat.com>
Replace the 2015 sphinx-quickstart boilerplate with a minimal modern
config. Switches html_theme from "default" to "alabaster" and removes
unused LaTeX, man page, and Texinfo output sections.
Signed-off-by: Haibo Lin <hlin@redhat.com>
There's a little thicket of code around this `failable` context
manager which is AFAICT only used for logging (in util.py and
compose.py). We can get more useful log messages for Kiwi task
failures by including the subvariant here. These are important
because they're read by compose-tracker and included in the
failed-composes tickets. Currently we get something like this:
[KIWIBUILD ] [ERROR ] [FAIL] Kiwibuild (variant Container, arch *) failed, but going on anyway.
If this works as intended we should instead get:
[KIWIBUILD ] [ERROR ] [FAIL] Kiwibuild (variant Container, arch *, subvariant FEX_RootFS) failed, but going on anyway.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Currently, we only include the variant in the global.log
"kiwibuild task" messages and the names of files in
logs/global/kiwibuild. That means we get rather unhelpful
logs, like this:
2026-03-30 05:57:58 [KIWIBUILD ] [INFO ] [BEGIN] kiwibuild task for variant Spins
2026-03-30 05:57:58 [KIWIBUILD ] [INFO ] [BEGIN] kiwibuild task for variant Spins
2026-03-30 05:57:58 [KIWIBUILD ] [INFO ] [BEGIN] kiwibuild task for variant Spins
2026-03-30 05:57:58 [KIWIBUILD ] [INFO ] [BEGIN] kiwibuild task for variant Spins
2026-03-30 05:57:58 [KIWIBUILD ] [INFO ] [BEGIN] kiwibuild task for variant Spins
2026-03-30 05:57:58 [KIWIBUILD ] [INFO ] [BEGIN] kiwibuild task for variant Spins
2026-03-30 05:57:58 [KIWIBUILD ] [INFO ] [BEGIN] kiwibuild task for variant Spins
...
and unhelpful filenames like this:
Labs-15-watch-task.log
Labs-16-watch-task.log
Labs-17-watch-task.log
Labs-18-watch-task.log
Labs-19-watch-task.log
Labs-20-watch-task.log
Including the profile in these should make them much more useful.
They should now look like:
[BEGIN] kiwibuild task for variant Spins profile Xfce-Live
and:
Spins-Xfce-Live-34-watch-task.log
Signed-off-by: Adam Williamson <awilliam@redhat.com>
If user explicitly wants to include a scratch build, we should allow
that even if the same NVR is already taken by a real build.
It is a rather unusual situation, as the scratch build could never be
rebuilt as a real build with the same NVR, but this gets us more
consistency with how extra builds are handled.
JIRA: RHELCMP-14814
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
There were 4 files using this library. Since we already require pytest
to run the tests, we can migrate the tests to use
pytest.mark.parametrize to achieve the same thing with one less library
being pulled in.
However, the pytest approach is not compatible with tests based on
`unittest.TestCase`. The relevant tests are thus rewritten to be purely
pytest based.
Assisted-By: claude-sonnet-4-5@20250929
Fixes: https://pagure.io/pungi/issue/1884
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
