Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

For compose debugging I don't think this part would be terrible in
practice, most of the time.

https://pagure.io/releng/failed-composes/issues

I'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.

--
_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux