On Tue, 28 Jan 2020 at 14:31, Paul Wouters <p...@nohats.ca> wrote: > > > > On Jan 28, 2020, at 18:45, Andrew Cagney <andrew.cag...@gmail.com> wrote: > > > >> On Tue, 28 Jan 2020 at 11:10, Antony Antony <ant...@phenome.org> wrote: > >> > >> I am curious what your thoughts now? > >> Is it a good idea to add " : ==== end ====" to nicinit.sh when final.sh is > >> not necessary. Or just Antony's preference? The test author can decide? > > > > As an instrument I find it blunt. It removes everything so useful > > stuff run during the post-mortem, such as checking for a core file, is > > lost. > > I see people using cut and paste and suddenly seeing multiple markers and > missing markers. So I prefer to not use it if we can avoid them. > > > My preference would be to get away from final.sh (instead have > > generic tear down code that, like swan-prep, runs silently unless > > there's a real error). > > final.sh has really been overloaded when what was needed was something > running on east after the run.sh. We have the numbered .sh method for that > now (especially if support for that is added to namespaces)
I thought that worked. The code's in fab/scripts.py. > I do think things like checking for cores and audit logs can be done outside > a .sh script. > > But shutdown is something I wouldn’t want there because often you want to ssh > into the test. Although if kvmrunner also will support —shutdown (and thus > not shutting down), than that could be useful (eg stock runs always having > leak-detective reports) The command: kvmrunner one-test doesn't shutdown the domains. The problem is that, to get and report a valid test result, all the .sh scripts need to be run - including final.sh and that unfortunately likes to kill libreswan. My idea is to replace final.sh with a teardown script that, unless there's a problem, leaves no trace in *.console.txt (but still spews all over *.console.verbose.txt so we can tell it ran). That way: kvmrunner one-test can skip the teardown but still report a "valid" result. If the teardown runs but doesn't make a sound ... _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
