On Wed, Mar 02, 2022 at 03:52:49PM +0100, Erik Skultety wrote: > On Wed, Mar 02, 2022 at 06:27:04AM -0800, Andrea Bolognani wrote: > > I don't think we can expect integration tests to be merged at the > > same time as a feature when new APIs are involved. If tests are > > written in Python, then the Python bindings need to introduce support > > for the new API before the test can exist, and that can't happen > > until the feature has been merged. > > Again, that is a logical conclusion which brings us to an unrelated process > question: How do we change the contribution process so that the contribution of > a feature doesn't end with it being merged to the C library, IOW we'd ideally > want to have a test introduced with every feature,but given that we'd need the > bindings first to actually do that, but we can't have a binding unless the C > counterpart is already merged, how do we keep the contributors motivated > enough? (Note that it's food for thought, it's only tangential to this effort) Yeah, let's save this massive topic for another time :) > > If the feature or bug fix doesn't require new APIs to be introduced > > this is of course not an issue. Most changes should fall into this > > bucket. > > > > So overall I still think using existing artifacts would be the better > > approach, at least initially. We can always change things later if we > > find that we've outgrown it. > > So, given that https://gitlab.com/libvirt/libvirt-perl/-/merge_requests/55 was > already merged we should not get to a situation where no artifacts would be > available because gitlab documents that even if artifacts expired they won't be > deleted until new artifacts become available, I think we can depend on the > latest available artifacts without building them. I'll refresh the patch > accordingly and test. Thanks! > > I think it's not unreasonable that when Red Hat, or any other entity, > > provides hardware access to the project there will be some strings > > attached. This is already the case for GitLab and Cirrus CI, for > > example. > > > > I could easily see the instance of libvirt-gitlab-executor running on > > hardware owned and operated by Red Hat returning a failure if a job > > submitted to it comes with DISTRO=debian-11. > > libvirt-gitlab-executor is supposed to be system owner agnostic, I'd even like > to make the project part of the libvirt gitlab namespace umbrella so that > anyone can use it to prepare their machine to be plugged into and used for > libvirt upstream integration testing. I absolutely agree and it was always my understanding that the project living under your personal account was only a temporary measure. > Therefore, I don't think the project is > the right place for such checks, those should IMO live solely in the > gitlab-ci.yml configuration. To be clear, I didn't mean that the software itself should contain hardcoded limits on what jobs it will process, but rather that it would make sense for it to offer a configuration setting along the lines of accept_distros: - "alpine-*" - "debian-*" that can be used by the local sysadmin to define such a policy. I guess this is already sort of already implicitly implemented due to the fact that a job will fail if the corresponding VM template does not exist... -- Andrea Bolognani / Red Hat / Virtualization
