[libcamera-ci] [RFC PATCH v1 2/3] Separate the building and running of unit tests

[Laurent Pinchart]

Hi Barnabás,

On Wed, Dec 18, 2024 at 10:24:50PM +0100, Barnabás Pőcze wrote:
> 2024. 12. 18. 2:10 keltezéssel, Laurent Pinchart írta:
> > On Tue, Dec 17, 2024 at 05:39:28PM +0000, Kieran Bingham wrote:
> >> Quoting Laurent Pinchart (2024-12-17 17:32:25)
> >>> On Tue, Dec 17, 2024 at 07:25:00PM +0200, Laurent Pinchart wrote:
> >>>>>>>> Couple observations:
> >>>>>>>>
> >>>>>>>> 1. The virtual pipeline handler configuration is not installed, so
> >>>>>>>>       that needs to be addressed. (Was this omitted intentionally?)
> >>>>>>
> >>>>>> I don't know. We have to be careful here, we don't want to virtual
> >>>>>> pipeline handler to end up being enabled with a default valid
> >>>>>> configuration in distributions, otherwise people will all of a sudden
> >>>>>> see virtual cameras poluting their devices list.
> >>>>>
> >>>>> I am not sure what should be done. Maybe a separate meson `install_tag`.
> >>>>> Or I suppose the configuration file could be created right before
> >>>>> running it?
> >>>>
> >>>> Hmmmm... If this is a sample configuration file that we don't want to
> >>>> install by default in the location where it will be lookup up, how about
> >>>> installing it as an example in doc_install_dir (e.g.
> >>>> /usr/share/doc/libcamera/) and name it virtual.yaml.example ? That seems
> >>>> to be a fairly common pattern.
> >>>
> >>> And then in CI we would take that file and copy it to the expected
> >>> location, renaming it to virtual.yaml.
> >>>
> >>> There's also the question of what install_tag to use. Other data files
> >>> use 'runtime', but those are installed to their runtime location. 'doc'
> >>> could be an option, we can use that even if we disable documentation
> >>> build in CI, but it may feel a bit weird, and possibly later install
> >>> other types of documentation that we way not want (although I suppose
> >>> installation of future "real" documentation could be conditioned by the
> >>> documentation meson option).
> >>>
> >>> Another option is to create it from scratch in CI (possibly with the
> >>> file just added to the CI repository and copied in the test job).
> >>
> >> Ultimately that's perhaps the 'easiest' option. But it would be nice to
> >> keep the CI aligned with any updates to the example virtual
> >> configuration too.
> > 
> > Yes, but if we consider that the virtual pipeline handler configuration
> > we use in CI has to be written for the needs of CI, then it should be
> > part of the libcamera-ci repository, and updated as the virtual pipeline
> > handler evolves.
> > 
> > On the other hand, the pipeline handler should pass lc-compliance with
> > any valid configuration, so it makes sense to test the example
> > configuration. Installing it to the documentation directory and then
> > copying it from there in the CI lc-compliance job sounds like a good
> > option (which contradicts what I wrote in a separate e-mail 2 minutes
> > ago :-)). Barnabás, what do you think ?
> 
> Not sure. To be honest I am not a fan of either solution, but I don't
> really ave an alternative idea. I suppose we could have a "special"
> camera(s) named something like "Virtual-CI" in the example configuration,
> which would be the one used in the CI test. Between these two options,
> keeping the configuration in the main repository seems better to me.

Agreed. Let's go for that, installing the configuration file as an
example, and copying it as part of the CI job.

-- 
Regards,

Laurent Pinchart