VSadov/Satori
1
0
Fork 0
mirror of https://github.com/VSadov/Satori.git synced 2025-06-12 02:30:29 +09:00
Code Activity

Update docs and comments to reflect the renames around build-test and runtest scripts (#42708)

Browse source 
* Move the script runtesttilstable.sh under src/tests

* Update most references to build-test / runtest in the runtime repo

With this change I can't find any remaining orphaned references to
the old script names except for a few superpmi-related scripts
I need to follow up on separately as I'm not too familiar with
their functionality.

Thanks

Tomas
This commit is contained in:
Tomáš Rylek 2020-09-25 14:28:59 +02:00 • committed by GitHub
parent 6b5b9f7242
commit bafb24c061
Signed by: github
GPG key ID: 4AEE18F83AFDEB23
16 changed files with 52 additions and 54 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/workflow/building/coreclr/linux-instructions.md
View file

@ -91,7 +91,7 @@ The Core_Root folder will contain the built binaries, generated by `build.sh`, a
the libraries subset (`-subset libs`) before this command can be run.
```
./src/coreclr/build-test.sh generatelayoutonly
./src/tests/build.sh generatelayoutonly
```
After the build is complete you will find the output in the `artifacts/tests/coreclr/Linux.x64.Debug/Tests/Core_Root` folder.
@ -99,7 +99,7 @@ After the build is complete you will find the output in the `artifacts/tests/cor
Running a single test
===================
After `src/coreclr/build-test.sh` is run, `corerun` from the Core_Root folder is ready to be run. This can be done by using the full absolute path to `corerun`, or by setting an environment variable to the Core_Root folder.
After `src/tests/build.sh` is run, `corerun` from the Core_Root folder is ready to be run. This can be done by using the full absolute path to `corerun`, or by setting an environment variable to the Core_Root folder.
```sh
export CORE_ROOT=/runtime/artifacts/tests/coreclr/Linux.x64.Debug/Tests/Core_Root

4
docs/workflow/building/coreclr/osx-instructions.md
View file

@ -66,7 +66,7 @@ Create the Core_Root
The Core_Root folder will have the built binaries, from `src/coreclr/build.sh` and it will also include the CoreFX packages required to run tests.
```
./src/coreclr/build-test.sh generatelayoutonly
./src/tests/build.sh generatelayoutonly
```
After the build is complete you will be able to find the output in the `artifacts/tests/coreclr/OSX.x64.Debug/Tests/Core_Root` folder.
@ -74,7 +74,7 @@ After the build is complete you will be able to find the output in the `artifact
Running a single test
===================
After `src/coreclr/build-test.sh` is run, corerun from the Core_Root folder is ready to be run. This can be done by using the full absolute path to corerun, or by setting
After `src/tests/build.sh` is run, corerun from the Core_Root folder is ready to be run. This can be done by using the full absolute path to corerun, or by setting
an environment variable to the Core_Root folder.
```sh

6
docs/workflow/testing/coreclr/running-aspnet-benchmarks-with-crossgen2.md
View file

@ -24,16 +24,14 @@ For Windows:
```powershell
.\build.cmd -subset clr+libs -c release
cd src\coreclr
.\build-test.cmd Release generatelayoutonly
.\src\tests\build.cmd Release generatelayoutonly
```
For Linux:
```bash
./build.sh -subset clr+libs -c release
cd src/coreclr
./build-test.sh -release -generatelayoutonly
./src/tests/build.sh -release -generatelayoutonly
```
### Generate a Configuration File for ASP.NET Benchmarking Runs

14
docs/workflow/testing/coreclr/testing.md
View file

@ -9,9 +9,9 @@ Details on test metadata can be found in [test-configuration.md](test-configurat
* [macOS](../../building/coreclr/osx-instructions.md)
* [Windows](../../building/coreclr/README.md)
2) [Build the libraries](../../building/libraries/README.md) in Release configuration. Pass the configuration of CoreCLR you just built to the build script (e.g. `-runtimeconfiguration debug`).
3) From the `src/coreclr` directory run the following command:
* Non-Windows - `./build-test.sh`
* Windows - `build-test.cmd`
3) From the root directory run the following command:
* Non-Windows - `src/tests/build.sh`
* Windows - `src\tests\build.cmd`
* Supply `-h` for usage flags
### Test priority
@ -21,16 +21,16 @@ The CoreCLR tests have two priorities, 0 and 1. The priority 0 tests run by defa
### Examples
* Build all tests priority 1 and higher
* `build-test.cmd -priority=1`
* `build-test.sh -priority1`
* `build.cmd -priority=1`
* `build.sh -priority1`
## Build Individual Test
Note: CoreCLR must be built prior to building an individual test. See the first step, above, for building all tests.
* Native Test: Build the generated CMake projects
* Projects are auto-generated when the `build-test.sh`/`build-test.cmd` script is run
* It is possible to explicitly run only the native test build with `build-test.sh/cmd skipmanaged`
* Projects are auto-generated when the `build.sh`/`build.cmd` script is run
* It is possible to explicitly run only the native test build with `build.sh/cmd skipmanaged`
* Managed Test: Invoke `dotnet build` on the project directly. `dotnet` can be the `dotnet.sh` or `dotnet.cmd` script in the repo root.
```
<runtime-repo-root>/dotnet.sh build <runtime-repo-root>/src/coreclr/tests/src/JIT/CodegenBringupTests/Array1_d.csproj /p:Configuration=Release

12
docs/workflow/testing/coreclr/unix-test-instructions.md
View file

@ -15,13 +15,13 @@ Dotnet CLI is required to build the tests. This can be done on any platform then
To build the tests on Unix:
```sh
./src/coreclr/build-test.sh
./src/tests/build.sh
```
Please note that this builds the Priority 0 tests. To build priority 1:
```sh
./src/coreclr/build-test.sh -priority1
./src/tests/build.sh -priority1
```
## Building Individual Tests
@ -41,16 +41,16 @@ During development there are many instances where building an individual test is
The following instructions assume that on the Unix machine:
- The CoreCLR repo is cloned at `/mnt/coreclr`
`src/coreclr/build-test.sh` will have set up the `Core_Root` directory correctly after the test build.
`src/tests/build.sh` will have set up the `Core_Root` directory correctly after the test build.
```sh
./src/coreclr/tests/runtest.sh x64 checked
./src/tests/run.sh x64 checked
```
Please use the following command for help.
```sh
./src/coreclr/tests/runtest.sh -h
./src/tests/run.sh -h
```
### Unsupported and temporarily disabled tests
@ -65,7 +65,7 @@ the conditional property
This property disables building of a test in a default build. It also
disables running a test in the bash/batch wrapper scripts. It allows the
test to be built on any target in CI when the `allTargets` option is
passed to the `build-test.*` scripts.
passed to the `build.*` scripts.
Tests which never should be built or run are marked

18
docs/workflow/testing/coreclr/windows-test-instructions.md
View file

@ -6,13 +6,13 @@ Building and running tests on Windows
Building coreclr tests must be done using a specific script as follows:
```
> src\coreclr\build-test.cmd
> src\tests\build.cmd
```
## Building Precompiled Tests
```
> src\coreclr\build-test.cmd crossgen
> src\tests\build.cmd crossgen
```
This will use `crossgen.exe` to precompile test executables before they are executed.
@ -20,7 +20,7 @@ This will use `crossgen.exe` to precompile test executables before they are exec
## Building Specific Priority Tests
```
> src\coreclr\build-test.cmd -priority=1
> src\tests\build.cmd -priority=1
```
The above is an example of requesting that priority '1' and below be built. The default priority value is '0'. If '1' is specified, all tests with `CLRTestPriorty` `0` **and** `1` will be built and run.
@ -30,18 +30,18 @@ The above is an example of requesting that priority '1' and below be built. The
To run a priority '0' and '1' and crossgen'd test pass:
```
> src\coreclr\build-test.cmd crossgen -priority=1
> src\tests\build.cmd crossgen -priority=1
```
For additional supported parameters use the following:
```
> src\coreclr\build-test.cmd -?
> src\tests\build.cmd -?
```
### Building Individual Tests
**Note:** `build-test.cmd skipmanaged [Any additional flags]` needs to be run at least once if the individual test has native assets.
**Note:** `build.cmd skipmanaged [Any additional flags]` needs to be run at least once if the individual test has native assets.
* Native Test: Build the generated Visual Studio solution or makefile corresponding to test cmake file.
@ -52,13 +52,13 @@ For additional supported parameters use the following:
Will list supported parameters.
```
> src\coreclr\tests\runtest.cmd /?
> src\tests\run.cmd /?
```
In order to run all of the tests using your checked build:
```
> src\coreclr\tests\runtest.cmd checked
> src\tests\run.cmd checked
```
This will generate a report named `TestRun_<arch>_<flavor>.html` (e.g. `TestRun_Windows_NT_x64_Checked.html`) in the subdirectory `<repo_root>\artifacts\log`. Any tests that failed will be listed in `TestRunResults_Windows_NT_x64_Checked.err`.
@ -78,7 +78,7 @@ There are 2 files of interest:
If you wish to re-run a failed test, follow the following steps:
1) Set an environment variable, `CORE_ROOT`, pointing to the path to product binaries that was passed to runtest.cmd.
1) Set an environment variable, `CORE_ROOT`, pointing to the path to product binaries that was passed to run.cmd.
For example using a checked build the location would be: `<repo_root>\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root`
2) Run the failed test, the command to which is also present in the test report for a failed test. It will be something like `<repo_root>\artifacts\tests\coreclr\Windows_NT.x64.Checked\Exceptions\Finalization\Finalizer.cmd`.

4
docs/workflow/testing/using-corerun.md
View file

@ -61,7 +61,7 @@ your new runtime.
## How CoreCLR Tests use corerun.exe
When you execute 'runtime/src/coreclr/build-test.cmd' one of the things that it does is set up a directory where it
When you execute 'runtime/src/tests/build.cmd' one of the things that it does is set up a directory where it
gathers the CoreCLR that has just been built with the pieces of the class library that tests need.
It places this runtime in the directory
```bat
@ -70,7 +70,7 @@ It places this runtime in the directory
off the CoreCLR Repository. The way the tests are expected to work is that you set the environment
variable CORE_ROOT to this directory
(you don't have to set CORE_LIBRARIES) and you can run any tests. For example after building the tests
(running build-test at the repository base) and running 'test\runtest') you can do the following
(running src\tests\build from the repository base) and running 'src\tests\run') you can do the following
```bat
set PATH=%PATH%;%CoreCLR%\artifacts\Product\Windows_NT.x64.Debug