On Wed, Oct 06, 2021 at 07:19:04AM +0530, Bharath Rupireddy wrote: > I was thinking of the same. +1 for "vcregress check-world" which is > more in sync with it's peer "make check-world" instead of "vcregress > all-taptest". I'm not sure whether we can also have "vcregress > installcheck-world" as well.
check-world, if it spins new instances for each contrib/ test, would be infinitely slower than installcheck-world. I recall that's why Andrew has been doing an installcheck for contribcheck to minimize the load. If you run the TAP tests, perhaps you don't really care anyway, but I think that there is a case for making this set of targets run as fast as we can, if we can, when TAP is disabled. > Having said that, with these new options, are we going to have only below? > > vcregress check > vcregress installcheck > vcregress check-world > vcregress installcheck-world (?) > > And remove others? My take is that there is value for both installcheck-world and check-world, depending on if we want to test on an installed instance or not. For CIs, check-world makes things simpler perhaps? > vcregress plcheck > vcregress contribcheck > vcregress modulescheck > vcregress ecpgcheck > vcregress isolationcheck > vcregress bincheck > vcregress recoverycheck > vcregress upgradecheck I don't really see why we should do that, the code paths are the same and the sub-routines would still be around, but don't cost much in maintenance. -- Michael
signature.asc
Description: PGP signature
