>> 1) Add `bro-pkg test <package>` command. > > Might it also make sense to just run the test on installation, before the > package is actually installed, to see if it works on the environment of > the user?
Yes, I like that idea. (I’d also want a flag or config option to opt-out of that behavior). > I actually think it would be neat to do this isolated, especially given > that this enables testing before installing. Not sure I follow. Can you explain further? From a typical user perspective, I think they would care more that the package’s tests pass in the final, installed state and it plays nice with any other site-specific stuff they have going on. Aborting an installation on test failure is also still possible — instead of bro-pkg cleaning up an isolated sandbox, it does the standard ‘remove’ operation to delete installed files. > It also makes it easier to > create something like "smokers" (Bro installations that just tro tu run > all testsuites of all available packages with a newer version to see if > something went wrong). Can you also go into more detail on what you’re thinking there? If there's concerns about accidentally corrupting an existing/production bro installation, the alternative I’d suggest would be to set up a separate bro-pkg config file for the smoke tests that would have bro-pkg install stuff in an isolated location. This allows users to explicitly define the testing sandbox for themselves. - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
