main,osbuildprogress: add --progress=text support (COMPOSER-2394)

[mvo5]

This adds a new bootc-image-builder mode that makes use of the
osbuild json-seq progress information. It will display some
user friendly progress information. It can be tested via:

$ cd bib/cmd/bootc-image-builder
$ echo '{}' > config.json
$ go build && sudo ./bootc-image-builder build --progress=text --store /var/tmp/osbuild-store --config config.json quay.io/centos-bootc/centos-bootc:stream9

It looks like this right now:

Building manifest-qcow2.json
Building [|]                                                                    
[4 / 8] step: image [------------------------->_________________________] 50.00%
[7 / 11] module: bootc.install-to-filesystem [---------------->_________] 63.64%
last msg: Starting module org.osbuild.bootc.install-to-filesystem              

It uses chegggaaa/pb/v3 - but there are still open questions about the message output and error handling.

Draft because:

• error handling is very sketchy, if something in the build fails the user gets a "failed" message but no context, we need to either make sure osbuild progress has a concept of an error and dump the entire output of the stage into this (as errors details tend to be inside the failed stage (this needs some osbuild work)
• no syncronisation between cmd.Wait() and the progress reader reading output, this also needs to get fixed via e.g. a waitgroup so that both the cmd needs to finish and the stdout read gets an EOF before we continue as otherwise the last progress messages may get lost
• tests (obviously) but that is tricky for progress, definitely some of the failure handling
• osbuild currently prints random non-json at the end of a run, we need to fix that or deal with it gracefully
• Naming of things like pipelines/source and stages
• Needs main,monitor: fix total steps in progress reporting osbuild#1826 for correct reporting

6. ... ?

[schuellerf]

As you already mentioned in the comment, I also think that the progress (at least the object itself) should have indefinite levels to be generic.

And the progress should definitely include "Generating manifest"
So basically the progress should start right after entering the application and should not only cover some main parts. (Those should be some sub-progress IMHO)

[schuellerf]

The way I think it should work is similar to a "logger" it should always exist and just be handed over (directly or indirectly/globally)

[mvo5]

We need to add "build_result"result here if/once osbuild/osbuild#1831 is merged

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days.

[mvo5]

As you already mentioned in the comment, I also think that the progress (at least the object itself) should have indefinite levels to be generic.

And the progress should definitely include "Generating manifest" So basically the progress should start right after entering the application and should not only cover some main parts. (Those should be some sub-progress IMHO)

Thanks, yeah, that is excellent feedback. This version was a draft and mostly to explore the space. I created #743 and osbuild/images#1047 now which are cleaned up versions based on this PR and address your points. I will close this one in favor of the other two.