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

[Laurent Pinchart]

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 ?

-- 
Regards,

Laurent Pinchart