On Tue, Jul 12, 2022 at 02:44:41PM +0200, Erik Skultety wrote: > Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx> > --- > docs/ci.rst | 39 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 39 insertions(+) > > diff --git a/docs/ci.rst b/docs/ci.rst > index bef023c521..ea1b839eac 100644 > --- a/docs/ci.rst > +++ b/docs/ci.rst > @@ -41,21 +41,60 @@ In case the integration test suite fails in our CI pipelines, a job artifact is > generated containing Avocado logs, libvirt debug logs, and the latest traceback > (if one was produced during a daemon's execution). > > +Adding new OS platforms OR build pre-requisites > +=============================================== > > +Since all of the Dockerfiles libvirt uses for CI have been generated by ``lcitool`` > +provided by the `libvirt-ci <https://gitlab.com/libvirt/libvirt-ci.git>`__ project, > +most relevant changes will need to be introduced to ``lcitool`` first. > > +In cases where ``libvirt-ci`` does not know about the OS distro/build > +pre-requisite that is desired to be tested, proceed with the following: > > + * Send a mail regarding your desired build/coverage change to libvir-list > > + Note that in case you're looking into adding a new OS platform there are > + limited CI compute resources available to libvirt, so the cost/benefit > + trade-off of adding new OS distros needs to be considered and > + is subject to a discussion on the mailing list. > > + * File an issue at https://gitlab.com/libvirt/libvirt-ci/-/issues > + pointing to the libvir-list mail thread in the archives. > > + This alerts other people who might be interested in the work > + to avoid duplication, as well as to get feedback from libvirt-ci > + maintainers on any tips to ease the addition. I feel it'd be sufficient to just have the libvirt-ci issue, as all the maintainers interested in CI pay attention to that, but no big deal either way. > +Assuming there is agreement to the change you wish to make then > > + #. Fork the ``libvirt-ci`` project on gitlab > > + #. > + * If adding a new OS distro, add metadata under > + ``guests/lcitool/lcitool/ansible/group_vars/`` > + for the new OS distro. There might be code changes required if > + the OS distro uses a package format not currently known. The > + ``libvirt-ci`` maintainers can advise on this when the issue > + is file. Edit the ``mappings.yml`` file to update all the existing package > + entries, providing details of the new OS distro **OR** > > + * If **NOT** adding a new OS distro, simply edit the ``mappings.yml`` file > + to provide a distro-agnostic mapping for the pre-requisite you're adding > > + #. Commit the ``mappings.yml`` change and submit a merge request to > + the ``libvirt-ci`` project > > + #. CI pipeline will run to validate that the changes to ``mappings.yml`` > + are correct, by attempting to install the newly listed package on > + all OS distributions supported by ``libvirt-ci`` > > + #. Once the merge request is accepted, go back to libvirt and update the > + ``ci/manifest.yml`` file to reflect your change I feel like these bits probably ought to be put in a doc like; $libvirt-ci.git/docs/new-distro.rst and just link to the git msater of that doc from here. GitLab renders the RST nicely enough, and it'd be nice to have these steps in a self-contained doc, so I can point QEMU maintainers to it too. > > + #. From the root of the libvirt git repository run > > +:: > > + $ lcitool manifest With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
