Re: jhalfs testing

On 10/12/22, "md" <[email protected]> wrote:
> Hi,
>
> When trying out jhalfs, I made a repository
> https://github.com/marcindulak/jhalfs-ci
> which uses github actions https://github.com/features/actions to perform
> and
> test the jhalfs build.
> It's a default setup which always takes the latest trunk of lfs and jhalfs.
> Using the scripts in the repo, a build can also be performed locally,
> inside
> of a docker container.
>
> The approach to building jhalfs is similar to the one taken by
> https://github.com/masmullin2000/LFScm:
> jhalfs is built inside of a docker container on a loopback device, and the
> resulting image booted in qemu.
>
> A build workflow takes about 6 hours.
> Since github actions give 2000 free minutes of the runners time per month,
> one can perform about 5 runs of the workflow monthly.
> This makes possible testing of jhalfs on a weekly cron schedule.
>
> The workflow generates so called artifacts at the end of a successful
> build:
> this includes the SBU report, installed-files, logs, test-logs and a qemu
> image.
> They can be downloaded, and inspected, and the quemu image could be used
> locally for boot.
> The qemu image is too large (~2GB) for the free github actions plan storage
> limit, so I'll disable it.
>
> Some possible actions based on the project:
> 1) A useful feature for debugging of would be if a particular build fails,
> to print its logs as part of the makefile target.
> I'm not sure what to do with the targets that generate megabytes of test
> output.
> Could you recommend an approach for implementing this?
> The thing is that the output preferably should not interfere with the
> output
> of `make BREAKPOINT` targets,
> since I'm using them for splitting the targets into shorter parts
> https://lists.linuxfromscratch.org/sympa/arc/alfs-discuss/2022-10/msg00013.html,
>
> 2) My plan is to let the cron schedule to trigger twice a month, and
> depending
> on how
> demanding the maintenance of the workflow is (the logging point 2. above
> would
> help),
> to maintain the project for some time.

Nice! Seems like a great use of CI. This is the kind of thing I think
would be useful to do more of, and would especially like to have ideas
like this in mind for any new alfs tools (or new revisions of jhalfs).

Which, btw, I updated the python proof-of-concept with a simple xml
parser for the LFS book in a testing branch:
https://github.com/automate-lfs/jhalfs/blob/testing/jhalfs/parser.py

JH

-- 
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page