-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Make the Settings Model tests into proper CI tests #16773
Conversation
…03/color-scheme-healing
…03/color-scheme-healing
…03/color-scheme-healing
…03/color-scheme-healing
…03/color-scheme-healing
…duhowett/what-if-localtests-didnt
…03/color-scheme-healing
…duhowett/what-if-localtests-didnt
It is important to note that these tests currently fail, because one of the profile tests has been broken since #15843 (very recently! this PR will prevent future regressions!) and one is broken on the test agent due to long file paths. Ha. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
now if only this worked with the TerminalApp ones too, oh man would that be sweet
I'd like to merge these green :) @zadjii-msft would you be able to look into the profile icon failure? @lhecker would you mind looking at the commandline normalization failure? We have seen smth like this before |
The good news is that the path normalization worked! The bad news is that the CI's username is too long. |
@lhecker yay! that worked! Now it's just Mike's 🥲 |
Done. I absolutely adore that these can run in CI now |
…b.com/microsoft/terminal into dev/duhowett/what-if-localtests-didnt
This pull request removes the need for the SettingsModel tests to run in
a UAP harness and puts them into the standard CI rotation.
This required some changes to
Run-Tests.ps1
to ensure that the rightte.exe
is selected for each test harness. It's a bit annoying, but forthings that depend on a
resources.pri
, that file must be in the samedirectory as the EXE that is hosting the test. Not the DLL, mind you,
the EXE. In our case, that's
TE.ProcessHost.exe
The bulk of the change is honestly namespace tidying.