On Wed, Jun 28, 2023 at 12:24 PM Jonathan Steffan <jonathansteffan@xxxxxxxxx> wrote:
On Wed, Jun 28, 2023 at 12:52 AM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:On Tue, 2023-06-27 at 17:59 -0600, Jonathan Steffan wrote:
> The Koji integration leaves many things to be desired. I've had to dig far
> more than needed for osbuildimage stuff.[...]> Maybe I'm just using it wrong, but I've not found a different way.
I will take a look. The difference between livemedia and osbuildImage is that the osbuildImage task is defined by a plugin and it interacts with koji via the content generator API. Koji sometimes have issues presenting information nicely for CGs. If anyone has more experience with Koji internals, help would be definitely appreciated.
For compose debugging I don't think this part would be terrible in
practice, most of the time.
https://pagure.io/releng/failed-composes/issuesI'm glad there is something better than what I'd found. I'm not necessarily trying to debug composes, just find them and use/test them as needed. If something like this continued after changing to osbuildimage tasks, that would work.Personally I don't usually have
much call for downloading the actual artifact from Koji - I'd usually
get it from the compose - but maybe you have a workflow where it's
important?I've regularly used the images produced at https://koji.fedoraproject.org/koji/builds?type=image&order=-build_id for doing live system testing for package updates and other changes where I don't have a local install already available. It's really nice to have these artifacts so easily understandable and accessible. Maybe my workflow is off, but having such artifacts available has been super useful. The osbuildimage tasks, not so much. If we start to migrate the live image creation into an osbuildimage task, as currently implemented, it will diminish the value of automatically generated install/live images. It has been very helpful to be able to grab an ISO from Koji and test whatever is needed in a live/virt environment without having to do a full install and keep it updated. Keeping that very easily accessible would be awesome.Personally, I'm more worried about the logs being JSON. Machine-
parseable is nice, I guess, but in practice it's usually humans who
parse logs, at least in this case, and I see no really nice human way
to consume that log.I agree.Maybe raw text in addition to the JSON logs would be better for this workload. For me, the logs on an "image" build are much more familiar to regular packagers doing builds and they make sense. I have to dig for logs/artifacts in two different places when trying to understand "osbuildimage" tasks. The tools for reading JSON are available, but it'd be great to add in some easily accessible raw logs.
We can definitely flatten the JSON output into something that resembles a log file. I will let you know when this is done.
Note that every task also produces a manifest file - this is extremely useful, because you can just feed it to osbuild locally. Since the manifest basically fully specifies an image build (with locked package versions including their hashes), there's a high chance that you will be just able to reproduce the issue locally and use any tools you want for deeper debugging. This is one of the goals of the project: Make image builds more reproducible.
Cheers,
Ondřej
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
