On Wed, 2020-04-08 at 15:56 +0200, Erik Skultety wrote: > On Wed, Apr 08, 2020 at 03:21:00PM +0200, Andrea Bolognani wrote: > > I guess you could drop the image element and replace it with > > > > tags: > > - fedora-31 > > ^This is what I had in mind > > > but then you'd either have to duplicate the job definition, or to > > only have the new one which then would not work for forks and merge > > requests, so that makes it less interesting. > > We'll have to duplicate it for FreeBSD anyway, so I don't understand why should > do it differently for other VM distros. We will not duplicate it, because there is no existing container based build for FreeBSD: the FreeBSD builds can, by definition, only happen inside VMs. > > I don't understand what you're trying to say here at all, sorry. > > What I meant is that I don't see much value to run the builds in VMs since we > have a bunch of images ready where we can already execute the builds Totally agree with you up until this point: this is exactly what I was trying to convey. > so it's > basically only about having resources to spawn the containers and that's where > OpenShift comes in. I still don't understand how OpenShift is part of the picture. I have probably either missed or forgotten something O:-) > I understand you reminding me that private runners cannot be used to run on > merge requests (and forks for obvious reasons), but the same applies to VMs > we're discussing in this thread. So, I wouldn't focus primarily on running the > builds there is what I'm saying. I think we're kind of talking past each other at this point :) To reiterate/clarify: I'm perfectly okay with using Linux VMs for integration testing only and leaving builds to shared runner and FreeBSD VMs. I don't think we should use Linux VMs for builds unless we use the docker executor for them, but then again I don't think we really need to use Linux VMs for builds in the first place. -- Andrea Bolognani / Red Hat / Virtualization
