CI: Add full test support

[bofh]

Summary

The patch adds support for running full tests in the local CI Environment. New features added:

• New target ci-full which runs the full test. This is also the default now
• Renamed the previous target ci-smokeit to ci-smoke
• Added user overridable variable CIDISABLED which supports disabling some tests. For now the available usages are disks, dtrace, notyet and zfs or a space separated mix of all of those.
• Unlike previous if the available memory is more than 16G a default of 8G will be used
• Added local installation of the xmlstartet pkg
• Removed some unnecessary debug messages
• Added dummybuf kernel module to the list of modules to be loaded on the VM

Things to do:

• I am still trying to make the results create some meaningful display in the terminal
• Start using these in our CI pipeline

Test Plan

The features that can be tested:

• make TARGET=<TARGET> TARGET_ARCH=<TARGET_ARCH> CITYPE=full ci
• make TARGET=<TARGET> TARGET_ARCH=<TARGET_ARCH> ci is also the same as above as CITYPE full is the default now

[bofh]

For now remove the codes related to disabling the tests. As per @lwhsu these tests are hacky and might be difficult to be removed in the future.

[lwhsu]

Is there a target to extract the test reports from meta disk of the VM to the host?

tests/ci/Makefile

75

Move this before the first use of BHYVE_EXTRA_DISK_PARAM

78

Where is this META_DIROUT being used?

79

Do we still need this as there is ci-create-meta target?

161

Where is xmlstarlet being used?

207

Why only these two commands get output suppressed?

[bofh]

• Unmute `ci-create-metaa directives
• Move BHYVE_EXTRA_DISK_PARAM?= close to the first use

[bofh]

tests/ci/Makefile

79

These DISCS has nothing to do with ci-create-meta target.

[lwhsu]

tests/ci/Makefile

79

The comment is not attached to the original lines after the differential has been updated. I mean the META_* variables. It seems META_DIR is in that target and will META_DIROUT be used in extract?

[lwhsu]

Speaking of using /tmp, is it possible to have a variable serves as a prefix? In the building machines, we don't have infinite /tmp space for many jobs running in parallel.

I don't think this would block merging this, but we need this for letting current Jenkins setup can use it. In Jenkins put everything related to job to ${WORKSPACE}, which will be set to job's workspace automatically.