Skip to content

[wasm] Add support for running debugger tests CI #62431

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 32 commits into from
Dec 16, 2021

Conversation

radical
Copy link
Member

@radical radical commented Dec 6, 2021

  • New CI builds to run wasm debugger tests on Linux, and Windows
    • Creates one helix job per test class
  • Adds new CI builds for runtime-staging, and runtime-manual
  • Adds a wrapper project - Wasm.Debugger.Tests to integrate DebuggerTestSuite in the library
  • Future TODO:
    • Generate the test classes to use for helix jobs, at build time
    • Use xunit.console instead of dotnet test
    • Once the failing, and unstable debugger tests are fixed, move the build to runtime

@ghost ghost added the area-Debugger-mono label Dec 6, 2021
@ghost
Copy link

ghost commented Dec 6, 2021

Tagging subscribers to this area: @thaystg
See info in area-owners.md if you want to be subscribed.

Issue Details

Attempt at an alternative, better way

Author: radical
Assignees: -
Labels:

area-Debugger-mono

Milestone: -

@radical radical added the arch-wasm WebAssembly architecture label Dec 6, 2021
@ghost
Copy link

ghost commented Dec 6, 2021

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Attempt at an alternative, better way

Author: radical
Assignees: -
Labels:

arch-wasm, area-Debugger-mono

Milestone: -

@radical radical mentioned this pull request Dec 6, 2021
@radical radical force-pushed the debugger-tests-alternative branch from 21353bf to 2e4f849 Compare December 6, 2021 21:00
@radical radical changed the title [wasm] Debugger tests #2 [wasm] Add support for running debugger tests CI Dec 6, 2021
Library projects don't have runtimeconfig.json files by default. So,
don't make it a warning. Instead, emit a low importance which might be
useful when debugging.

But library projects can have runtimeconfig.json, like the runtime test
projects. So, don't limit processing that by OutputType.

IOW, if it's found then use it.
Instead of trying to use the script from `.dotnet`, download the script.
`.dotnet` might not exist, for example, when the `global.json` version
matches the system installed one.
Some helper methods have a `Action<JToken>` parameter. Many tests
pass an async lambda to this, expecting it to get awaited upon.

```csharp
    EvaluateAndCheck (Action<T> locals_fn)
    {
        ...
        locals_fn(); // no await
        ...
    }

    async Task Test()
    {
        EvaluateAndCheck( async (locals) => {
            ...
            CheckNumber(locals, ...);

            await CheckDateTime(locals, ..);
            ...

        } );
    }
```

In the above example, roslyn generates an async-void lambda, so the
compiler never complains about the async lambda being passed.
`EvaluateAndCheck` cannot, and does not await this, but if the lambda happens to
block, then it will return at that point, and the test(calling method) will end,
without ever completing the lambda. And for most tests, the actual
checks are done in that lambda.

This gets hit when `CheckDateTimeValue` tries to fetch properties of a
`DateTime` object. And it started to show up when adding
`ConfigureAwait(false)` to some calls.
This is a proxy/wrapper project for `src/mono/wasm/debugger/DebuggerTestSuite/DebuggerTestSuite.csproj`.

- Building the project as part of the regular browser-wasm build
  presents some issues, because of part the tests need use the aspnet
  sdk, and that doesn't work with `browser-wasm`.
- This wrapper project essentially builds the `DebuggerTestSuite`
  project, with some
  properties(`TargetFramework;TargetFrameworks;Configuration;TargetOS;TargetArchitecture`)
  removed so they don't propogate from the parent build.
  - And it packages it up for running the tests on helix

- I did try to convert `DebuggerTestSuite` into a `Wasm.Debugger.Tests`,
  and make it use the library tests infrastructure, but ran into an
  issue
  - it built the project with no `testhost.dll`, so can't use `dotnet
    test`
  - it did get `xunit.console.dll`, but that would fail to run the tests
    because of missing `System.Runtime` (and I'm guessing, other
    assemblies)
    - attempts to publish the project failed
    - So, for now, this is what we have!
.. like on helix.

Add new `DEBUGGER_TEST_PATH`, and `CHROME_PATH_FOR_DEBUGGER_TESTS` which
will be set for helix.

And change the appbundle directory name from the misleading `publish/`
to `AppBundle/`.
Also, added `eng/testing/scenarios/WasmDebuggerTestsJobsList.txt` which
is a manually generated list of test classes. This will be changed to be
generated at runtime, in an upcoming PR.
They follow the same pattern as other wasm jobs:

- build when isFullMatrix
- build in runtime-manual
- Additionally, build when there are changes in:

```
  - src/mono/wasm/debugger/*
  - src/mono/wasm/runtime/*
  - src/mono/mono/*
```
`submit-debugger-tests-helix`
`submit-tests-helix` - submits any library test archives
Essentially, disable use of SourceLink which gets enabled by default
when using `-p:ContinuousIntegrationBuild=true`.

Issue: dotnet#62618
@radical radical force-pushed the debugger-tests-alternative branch from 1ed38d5 to 64635f4 Compare December 10, 2021 10:49
.. file when running for Wasm.Build.Tests, or Wasm.Debugger.Tests .
Issue: dotnet#62661

Using `[Trait..` instead of `ActiveIssue` because: dotnet#62660
@radical radical force-pushed the debugger-tests-alternative branch from dfc2b46 to 610687b Compare December 10, 2021 23:49
@radical radical marked this pull request as ready for review December 10, 2021 23:55
@radical radical requested a review from marek-safar as a code owner December 10, 2021 23:55
@radical
Copy link
Member Author

radical commented Dec 14, 2021

/azp run runtime-manual

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

`DebuggerTests.BreakpointTests.BreakpointInAssemblyUsingTypeFromAnotherAssembly_BothDynamicallyLoaded`

Issue: dotnet#62823
Copy link
Member

@thaystg thaystg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks @radical

@thaystg thaystg merged commit ad3f1c1 into dotnet:main Dec 16, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Jan 15, 2022
@radical radical deleted the debugger-tests-alternative branch January 19, 2022 11:45
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-Debugger-mono
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants