Treat warnings as errors for initial projects

[emmagarland]

Treat warnings as errors for initial projects:

• templates/Umbraco.Templates
• Umbraco.Cms
• Umbraco.Cms.Api.Common
• Umbraco.Cms.Imaging.ImageSharp
• Umbraco.Cms.Imaging.ImageSharp2
• Umbraco.Cms.Persistence.EFCore.Sqlite
• Umbraco.Cms.Persistence.EFCore.SqlServer
• Umbraco.Cms.StaticAssets
• Umbraco.Cms.Targets

Prerequisites

• I have added steps to test this contribution in the description below

If there's an existing issue for this PR then this fixes #15015

Description

There are numerous warnings in the Umbraco source code. I have created an issue #15015 to suggest removing these warnings.

To ensure that warnings don't creep back in, I propose setting warnings as errors project-by-project (as these warnings are removed). This will help ensure that we no longer end up in a situation with so many warnings, because people/the build server will not be able to compile the code with warnings in it.

(Conversations with HQ have approved this initiative)

[github-actions]

Hi there @emmagarland, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[mikecp]

Thanks @emmagarland for initiating this warning cleanup 👍

I like the idea of preventing those warnings to come back, but I'm wondering if treating all as error would not have the side effect that people would just set "ignore" flags on those warnings? On the other hand, I don't see what else we could put in place 😅

[emmagarland]

@mikecp I get what you mean, but in my experience of doing this on other projects, that hasn't happened. And if it did, the pull request reviewers would be able to comment about it and hopefully it wouldn't be a problem 👍

[mikecp]

Yes it's true, we'll just need to watch out 😁

[emmagarland]

@mikecp it will take a while to remove all warnings from some of the projects, anyway. Perhaps, if HQ are happy to try this, we could merge this PR with warnings as errors initially, and see how it goes?

[mikecp]

@emmagarland Yes indeed I guess we could give it a try if that would be OK for HQ. And it shouldn't be too complex to come back to the current situation if needed 😉

[emmagarland]

@mikecp this PR is ready for review, presuming HQ are ok to try this approach on some initial projects?

I think @Migaroez was handling this in terms of HQ?

[Migaroez]

Hey y'all

HQ is ok with the approach. As soon as all warnings have been removed in a given project, this setting can be turned on for that project.

Thanks for all the work @emmagarland #H5YR!

[emmagarland]

Ah that's amazing! Thanks so much @Migaroez for sorting. I'll hopefully get some time to do some more on Friday. 😃

[emmagarland]

(Switching back to draft as more warnings have been introduced since the initial PR that I need to fix/remove)

[emmagarland]

@Migaroez It's been a while, but I've merged from v14 and removed some where warnings had come in, but there's still a fair few warnings as errors switched on here.

Thanks!

[ronaldbarendse]

Great initiative! A cleaner way to gradually enable this on all projects would be to add <TreatWarningsAsErrors>true</TreatWarningsAsErrors> to Directory.Build.props (in the property group next to WarningsAsErrors, omitting the conditions used in this PR) and then disable them per project:

<PropertyGroup>
  <!-- TODO: Fix all warnings and remove this override -->
  <TreatWarningsAsErrors>false</TreatWarningsAsErrors>
</PropertyGroup>

Or only for specific warning numbers, like CS0618 (referenced obsolete members):

<PropertyGroup>
  <!-- TODO: Remove all usages of obsolete members and remove this override -->
  <WarningsNotAsErrors>CS0618</WarningsNotAsErrors>
</PropertyGroup>

Package validation uses a similar approach:

Umbraco-CMS/Directory.Build.props

Line 32 in d105968

<EnablePackageValidation>true</EnablePackageValidation>

Umbraco-CMS/src/Umbraco.Web.UI/Umbraco.Web.UI.csproj

Line 5 in 9c58714

<EnablePackageValidation>false</EnablePackageValidation>

[emmagarland]

Cool, I like that idea @ronaldbarendse. I'll tweak that later and push the updates.

[emmagarland]

Hi @ronaldbarendse and @Migaroez

Thanks for the suggestion, I've now updated as per the PR request to update the Directory.Build.props file to set all warnings as errors and then remove them on a project basis. I've done a specific removal for smaller numbers of warnings, and then a catch-all where there are many different warning codes.

Please let me know if you have any other feedback,

Thanks

Emma

[Migaroez]

Hey Emma, I am still seeing a few errors creep up on your branch

GoogleBackOfficeExternalLoginProviderOptions.cs(30, 40): [CS0618] 'Constants.Security.EditorGroupAlias' is obsolete: 'Use EditorGroupKey instead. Scheduled for removal in V15.'

ContextualAuthorizeAttribute.cs(114, 41): [CS1998] This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.

ContextualAuthorizeAttribute.cs(72, 9): [SA1117] The parameters should all be placed on the same line or each parameter should be placed on its own line (https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/SA1117.md)
  
GoogleBackOfficeExternalLoginProviderOptions.cs(43, 9): [SA1111] Closing parenthesis should be on line of last parameter (https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/SA1111.md)
    
PerformanceHelper.cs(11, 14): [SA1649] File name should match first type name (https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/SA1649.md)

[emmagarland]

Thanks Sven, I didn’t catch that locally when I built it so I’ll check it out later today

…

On Mon, 26 Aug 2024 at 11:50, Sven Geusens ***@***.***> wrote: Hey Emma, I am still seeing a few errors creep up on your branch GoogleBackOfficeExternalLoginProviderOptions.cs(30, 40): [CS0618] 'Constants.Security.EditorGroupAlias' is obsolete: 'Use EditorGroupKey instead. Scheduled for removal in V15.' ContextualAuthorizeAttribute.cs(114, 41): [CS1998] This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread. ContextualAuthorizeAttribute.cs(72, 9): [SA1117] The parameters should all be placed on the same line or each parameter should be placed on its own line (https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/SA1117.md) GoogleBackOfficeExternalLoginProviderOptions.cs(43, 9): [SA1111] Closing parenthesis should be on line of last parameter (https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/SA1111.md) PerformanceHelper.cs(11, 14): [SA1649] File name should match first type name (https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/SA1649.md) — Reply to this email directly, view it on GitHub <#15019 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMSZPYIAYT7AP6SYA73AMDZTMCAVAVCNFSM6AAAAAA6LAU2OWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBZHEYTOMBXGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Migaroez]

I am an idiot, these things are from my test stash🤦 All good to go.

The only thing that worries me is the pipeline failing on the code analyzers. I had a similar issue when first checking out your branch. But it got auto resolved after swapping branches back and forth 🤷 I can't find any packages that are different from v14/dev...

[Migaroez]

I added 2 commits. The sdk one is cherry picked from #16963 so the pipeline can run before merging into contrib
The second one is another error that pops up later in the pipeline when the static assets are compiled. (picked from a test branch that had a successful pipeline run)

[emmagarland]

Nice one @Migaroez, sounds good with those cherry picked build fixes!