Enable Windows ARM32 corefx testing
authorBruce Forstall <brucefo@microsoft.com>
Thu, 25 Jan 2018 00:27:52 +0000 (16:27 -0800)
committerBruce Forstall <brucefo@microsoft.com>
Tue, 6 Feb 2018 19:07:05 +0000 (11:07 -0800)
commitd593111e84c102e8fa65692feccfed5cd126ccf3
treef041a684cbde6807cac230c7cecf6234bbdb33d8
parentc67c29d6e226e4cca1f1efb4d57b7f498d58b534
Enable Windows ARM32 corefx testing

We create a flow job for each arm32 corefx mode, e.g.
arm_cross_checked_windows_nt_corefx_jitstress1_flow_prtest. This
depends on a build job that is specific to the stress mode, e.g.
arm_cross_checked_windows_nt_corefx_jitstress1_bld_prtest, which
(on x64) builds CoreCLR, then clones and builds CoreFX using run-corefx-tests.py.
In particular, it only builds the CoreFX tests; it doesn't run them.
Note that because the CoreFX test build embeds the stress mode environment
variables in its generated RunTests.cmd scripts, we need a different
corefx build dependency for each corefx test run; we can't share the
builds. The build script then ZIPs up the CoreFX tests and generated
CoreFX runtime (which will include the coreclr runtime because we built
CoreFX with the `/p:CoreCLROverridePath` argument), and archives these.

The test job, which runs on an arm64 machine, then copies the ZIPed
tests and runtime, unzips them, and runs a batch script to run each
RunTests.cmd file. Note that we don't use any existing mechanism to
run each test (such as msbuild), and I believe the CoreFX msbuild
harness doesn't have any mechanism to just run a previously built set of tests.

There is a very simple test exclusion mechanism: an entire test assembly
can be excluded by putting its name (e.g., System.IO.Ports.Tests), in
a file (e.g., tests\arm\corefx_test_exclusions.txt).

Note that this corefx testing mechanism is only enabled for arm
(aka arm32), not armlb or arm64.
netci.groovy
tests/arm/corefx_test_exclusions.txt [new file with mode: 0644]
tests/scripts/run-corefx-tests.bat [new file with mode: 0644]
tests/scripts/run-corefx-tests.py