Skip to content
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 ALL template warnings show up as test errors (not just C# warnings), and produce more diagnostic artifacts #17637

Merged
merged 5 commits into from Oct 2, 2023

Conversation

Eilon
Copy link
Member

@Eilon Eilon commented Sep 25, 2023

Right now we correctly set TreatWarningsAsErrors=true for template tests, but that catches only C# compiler warnings and converts those to errors. It does not treat MSBuild warnings as errors. So, any warning during build/publish/whatever that isn't a C# compiler warning is ignored during our tests. And I think this is why #17561 lingered un-caught for a while.

This PR has a few parts:

  1. Make sure MSBuild warnings fail the build with a specific warnaserror MSBuild option. This is different from the C# TreatWarningsAsErrors=true option. There's info here on that: https://stackoverflow.com/a/47448331/31668
  2. Address current warnings that we've been missing or aren't worried about: there are two of these, which you can see in the excluded warnings in the test code.
  3. Have the build produce more artifacts even during successful runs. I spent hours trying to get a binlog for successful template test runs (I can't run them locally for an unknown reason). We now attach artifacts for all test runs (success or failure) and you can get test console output as well as binlogs to view/download. With this PR you can download binlogs for any template test and then view locally with https://msbuildlog.com/ online or with an installable app

image

cc @mattleibow @PureWeen

(This PR is a replacement for #17586.)

- Ensure all template build warnings are caught as errors and make the tests fail
- Save template test output as artifacts
@Eilon Eilon added the area/templates 📄 Project templates, Item Templates for Blazor and MAUI label Sep 25, 2023
@Eilon Eilon marked this pull request as ready for review September 25, 2023 22:29
@Eilon Eilon requested a review from a team as a code owner September 25, 2023 22:29
@Eilon
Copy link
Member Author

Eilon commented Sep 26, 2023

Also tagging @pjcollins because it looks like most of this test infrastructure was introduced in #13662.

@@ -98,25 +98,10 @@ public void BuildTestSetUp()
[TearDown]
public void BuildTestTearDown()
{
// Clean up test or attach content from failed tests
Copy link
Member Author

Choose a reason for hiding this comment

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

I deleted the code that would clean up test artifacts if the test passed. As it turned out, tests were passing despite there being bugs in the product, but successful tests had no logs. With this change, every template test has binlogs and console output making it a lot easier to understand why a test passed even though perhaps it should have failed.

Copy link
Member

Choose a reason for hiding this comment

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

What happens if we re-run ? this would previous delete the previous results. My issue here is if they can get mixed up if have similar names. Do you know if we add the DateTime stamp to these logs?

Copy link
Member Author

Choose a reason for hiding this comment

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

Rerun I think is fine because it presumably always gets a clean instance, no? I assume that because there are all kinds of ways test can fail without cleanup running and I'd hope that wouldn't cause a rerun to fail?

@@ -123,12 +123,11 @@ public void PackCoreLib(string id, string framework, string config)
EnableTizen(projectFile);
FileUtilities.ReplaceInFile(projectFile, new Dictionary<string, string>()
{
{ "UseMaui", "UseMauiCore" },
Copy link
Member Author

Choose a reason for hiding this comment

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

This was here from the original tests introduced in #13662. I took it out because:

  1. It causes the template build to produce the notorious MA002 MAUI MSBuild warning (which I made into an error for the test). The warning was produced because the template is authored to have a correct Microsoft.Maui.Controls reference (to match UseMaui), but this test changes UseMaui to UseMauiCore, but without the required Microsoft.Maui reference, thus producing this warning (which becomes an error).
  2. It's apparently unnecessary (the test passes now without any warnings)

Copy link
Member

Choose a reason for hiding this comment

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

Do we have a test for usemauicore still. This is a feature we need. Probably not essential anymore since we have nugets, but it should only add half of maui

Copy link
Member Author

Choose a reason for hiding this comment

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

We might not have such a test now, but I think for this template test it's best to test the template as close to reality as possible (because that's what customers use). If we want an additional test scenario I think that should be a separate test.

Copy link
Member Author

Choose a reason for hiding this comment

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

Also I think I mentioned somewhere that the test as-is was somewhat incorrect anyway, because it specified UseMauiCore without adding the correct package reference, which is something we literaly warn people not to do 😄

Copy link
Member

@pjcollins pjcollins Sep 27, 2023

Choose a reason for hiding this comment

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

For some more context we do test the mauilib template without any modifications as part of the Build test here:

[TestCase("mauilib", DotNetPrevious, "Debug", true)]
[TestCase("mauilib", DotNetPrevious, "Release", true)]
[TestCase("mauilib", DotNetCurrent, "Debug", true)]
[TestCase("mauilib", DotNetCurrent, "Release", true)]
public void Build(string id, string framework, string config, bool shouldPack)

Maybe we should just put an [Ignore] attribute on the PackCoreLib test for now and fix it in a follow up PR?

Edit - I just saw the related comment below, I think it would also be fine to merge this as is and fix it separately.

Copy link
Member Author

Choose a reason for hiding this comment

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

@mattleibow alright I put back this test, but also made it change the MAUI Controls reference to be a MAUI Core reference.

@@ -34,6 +34,26 @@ public static bool Build(string projectFile, string config, string target = "",
binlogPath = Path.Combine(Path.GetDirectoryName(projectFile) ?? "", binlogName);
}

if (msbuildWarningsAsErrors)
Copy link
Member Author

Choose a reason for hiding this comment

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

This section is what now causes the template tests to treat MSBuild warnings as errors. There are two excluded warnings (see below, with justification). I originally had the sample tests also do this, but our samples are not nearly as cleanly authored, and aren't as important, so the samples tests do NOT treat MSBuild warnings as errors.

TestContext.WriteLine(runOutput);
TestContext.WriteLine($"Process exit code: {exitCode}");
TestContext.WriteLine($"-------- Process output start --------");
TestContext.WriteLine(runOutput);
Copy link
Member Author

Choose a reason for hiding this comment

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

This produces more details in the console log output of the tests, which greatly aid in debugging tests even when they pass.

pjcollins
pjcollins previously approved these changes Sep 26, 2023
Copy link
Member

@pjcollins pjcollins left a comment

Choose a reason for hiding this comment

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

Changes here make sense and LGTM assuming CI is also happy

@Eilon
Copy link
Member Author

Eilon commented Sep 27, 2023

Changes here make sense and LGTM assuming CI is also happy

Thanks @pjcollins . Do you happen to have any idea about why this setting was changed for the test? https://github.com/dotnet/maui/pull/17637/files#r1337777334 . It ends up causing the MA002 warning because it creates a semi-invalid CSPROJ file. And the test works fine without it.

@Eilon
Copy link
Member Author

Eilon commented Sep 27, 2023

Alright, tests all pass. @mattleibow / @PureWeen - do either of you want to take a quick look before I merge?

@pjcollins
Copy link
Member

Thanks @pjcollins . Do you happen to have any idea about why this setting was changed for the test? https://github.com/dotnet/maui/pull/17637/files#r1337777334 . It ends up causing the MA002 warning because it creates a semi-invalid CSPROJ file. And the test works fine without it.

This property was added when porting over the "core library" test here: https://github.com/dotnet/maui/pull/13662/files#diff-f987df2e4d48c04c42bb417e36d0d8b1fa9ddd29f10459c98f16d7b9b10f47c5L195. As Matthew mentioned above we may want to keep it and ignore the warning for that specific test to ensure we have a test covering this scenario?

@Eilon

This comment was marked as outdated.

@Eilon Eilon enabled auto-merge (squash) September 27, 2023 16:19
@Eilon
Copy link
Member Author

Eilon commented Sep 29, 2023

The UseMauiCore test is restored to its original glory, but I updated it to have a CSPROJ that correctly avoids MA002 by updating the package references. So, now this PR is not changing which scenarios the tests cover.

@Eilon
Copy link
Member Author

Eilon commented Oct 2, 2023

@rmarinho / @mattleibow - this PR requires an approval to merge. Are there any further changes required to this PR? (This test would have helped prevent several bugs that shipped in previews, so I'd love to have it in place to prevent future bugs.)

@Eilon Eilon merged commit 1ea2808 into main Oct 2, 2023
47 checks passed
@Eilon Eilon deleted the eilon/template-errors-catcher branch October 2, 2023 17:41
rachelkang pushed a commit that referenced this pull request Oct 25, 2023
…gs), and produce more diagnostic artifacts (#17637)

- Ensure all template build warnings are caught as errors and make the tests fail
- Save template test output as artifacts even if they pass
@github-actions github-actions bot locked and limited conversation to collaborators Dec 6, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/templates 📄 Project templates, Item Templates for Blazor and MAUI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants