Skip to content

Many Android JIT tests failing in CI #44306

Closed

Description

@ViktorHofer

https://dev.azure.com/dnceng/public/_build/results?buildId=873257&view=ms.vss-test-web.build-test-results-tab

Configuration: Mono Android x64 Release @ Ubuntu.1804.Amd64.Android.Open

@akoeplinger @steveisok is this known?

Runfo Tracking Issue: Many Android JIT tests failing in CI

Build Definition Kind Run Name Console Core Dump Test Results Run Client
956620 runtime PR 47182 net6.0-Android-Release-arm64-Mono_Release-Windows.10.Amd64.Android.Open console.log runclient.py
945073 runtime PR 46810 net6.0-Android-Release-arm64-Mono_Release-Windows.10.Amd64.Android.Open console.log runclient.py
944893 runtime PR 46810 net6.0-Android-Release-arm64-Mono_Release-Windows.10.Amd64.Android.Open console.log runclient.py

Build Result Summary

Day Hit Count Week Hit Count Month Hit Count
0 0 0

Activity

  1. Dotnet-GitSync-Bot commented on Nov 5, 2020

    @Dotnet-GitSync-Bot
    Collaborator

    I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

  2. changed the title [-]Many Android tests failing in rolling build CI[/-] [+]Many Android runtime tests failing in rolling build CI[/+] on Nov 5, 2020
  3. changed the title [-]Many Android runtime tests failing in rolling build CI[/-] [+]Many Android JIT tests failing in CI[/+] on Nov 5, 2020
  4. ViktorHofer commented on Nov 5, 2020

    @ViktorHofer
    MemberAuthor
  5. removed
    untriagedNew issue has not been triaged by the area owner
    on Nov 5, 2020
  6. ViktorHofer commented on Nov 5, 2020

    @ViktorHofer
    MemberAuthor

    @danmosemsft the bot isn't mentioning anyone, intentional?

  7. steveisok commented on Nov 5, 2020

    @steveisok
    Member

    So, https://dev.azure.com/dnceng/public/_build/results?buildId=873257&view=ms.vss-test-web.build-test-results-tab is a result of an apk installation failure. That impacted 50+ tests on two runs from #38457

    It looks like work items completed on the machine that failed afterwards, so my guess is that adb is in a bad state and may be corrected upon the work item finishing. We can look into making this more resilient.

    The other issues linked in by runfo appear to be different. My guess on some would adb corruption occurring at different points in time.

  8. danmoseley commented on Nov 5, 2020

    @danmoseley
    Contributor

    @danmosemsft the bot isn't mentioning anyone, intentional?

    The owner is @vargaz -- @vargaz do you want notifications for this area label?

  9. akoeplinger commented on Nov 5, 2020

    @akoeplinger
    Member

    @ViktorHofer all of the failures from #43740 are known, we're iterating on replacing OpenSSL on Android there.

  10. ViktorHofer commented on Nov 11, 2020

    @ViktorHofer
    MemberAuthor

    @steveisok what do you think would be a reasonable follow-up action? The day hit count is concerningly high. Assuming that disabling the Android leg in CI is a no go, should we move the job into a different pipeline that doesn't fail the build: #44031?

    cc @safern @jkoritzinsky for opinions

  11. fanyang-mono commented on Nov 11, 2020

    @fanyang-mono
    Member

    I wonder why this only happened to runtime tests? Theoretically, library tests should be affected as well.

  12. steveisok commented on Nov 11, 2020

    @steveisok
    Member

    I'm trying to sort through the recent data first and that may help what a good follow up action will be.

  13. 8 remaining items

  14. added a commit that references this issue on Nov 26, 2020
  15. ViktorHofer commented on Nov 30, 2020

    @ViktorHofer
    MemberAuthor

    I see tons of Android failures in many PRs today :(

  16. safern commented on Dec 1, 2020

    @safern
    Member

    Note that I just merged my staging pipeline PR which moved the Android tests that use the emulator.

  17. fanyang-mono commented on Apr 19, 2021

    @fanyang-mono
    Member

    Runtime tests have been running reliably on Android x64 for quite a while now. I wonder if it could be moved to a regular pipeline? Lately, there are real issues weren't fixed by the introduced PR, because the staging lane checks are always green.

  18. ViktorHofer commented on Apr 19, 2021

    @ViktorHofer
    MemberAuthor

    "Reliably" isn't measurable. If the android runtime tests pass rate numbers in the last 7-14 days have been above 90% then I agree that they should be moved into the main pipeline.

  19. fanyang-mono commented on Apr 19, 2021

    @fanyang-mono
    Member

    "Reliably" isn't measurable. If the android runtime tests pass rate numbers in the last 7-14 days have been above 90% then I agree that they should be moved into the main pipeline.

    Where could I get that data?

  20. ViktorHofer commented on Apr 19, 2021

    @ViktorHofer
    MemberAuthor

    AzDO REST APIs or Kusto. You will likely need to write a custom query to filter on just the android runtime tests.

  21. ViktorHofer commented on Apr 19, 2021

    @ViktorHofer
    MemberAuthor

    maybe @steveisok already has a query for that?

  22. SamMonoRT commented on Jun 24, 2021

    @SamMonoRT
    Member

    @fanyang-mono : I think we have most of these tests passing after your recent PRs, and the ones which are failing have individual issues logged. Do we still need this open ?

  23. fanyang-mono commented on Jun 24, 2021

    @fanyang-mono
    Member

    Lane Mono Android x64 Release @ Ubuntu.1804.Amd64.Android.Open has been stable and moved back to regular pipeline. Closing this issue.

  24. ghost locked as resolved and limited conversation to collaborators on Jul 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions