Hi, On 2023-02-09 17:00:48 -0800, Peter Geoghegan wrote: > On Thu, Feb 9, 2023 at 4:33 PM Andres Freund <and...@anarazel.de> wrote: > > I e.g. have a not-quite-done patch that creates a "template initdb", which > > pg_regress and tap tests automatically use (except if non-default options > > are > > required), which quite noticably reduces test times (*). But something > > needs to > > create the template initdb, and initdb doesn't run without an installation, > > so > > we need to run it after the temp_install. > > > > Of course we could wrap that into one "test", but it seemed nicer to see if > > you fail during installation, or during initdb. So for that I added a > > separate > > test, that is also part of the setup suite. > > But what are the chances that the setup / tmp_install "test" will > actually fail? It's almost a test in name only.
I've seen more failures than I'd like. Permission errors, conflicting names, and similar things. But mainly that was a reference to running initdb, which I've broken temporarily many a time. > > Of course we could still name the suite tmp_install (or to be consistent > > with > > the confusing make naming, have a temp-install target, which creates the > > tmp_install directory :)). I guess that'd still be less confusing? > > Yes, that definitely seems like an improvement. I don't care about the > tiny inconsistency that this creates. Then lets do that - feel free to push something, or send something for review. Otherwise I'll try to get to it, but I owe a few people work before this... > I wonder if this could be addressed by adding another custom test > setup, like --setup running, used whenever you want to just run one or > two tests against an ad-hoc temporary installation? Offhand it seems > as if add_test_setup() could support that requirement? What precisely do you mean with "ad-hoc temporary installation"? I was wondering about adding a different setup that'd use the "real" installation to run tests. But perhaps that's something different than what you have in mind? The only restriction I see wrt add_test_setup() is that it's not entirely trivial to use a "runtime-variable" path to an installation. Greetings, Andres Freund
