Converge "KoreBuild" and Arcade

[markwilkie]

The way arcade builds, tests, packages, signs, and publishes must be directly usable by all repos in the stack. Among other things, it provides the following value:

• Consistency across repos for devs
• Implements the "repo API", making adoption more straight forward
• Allows for reasonable updates and improvements across the entire stack
• More efficient, in that there's only one implementation for shared eng

This epic is considered complete when:

• Arcade has the changes necessary for KoreBuild repos
• All KoreBuild driven changes are useful across the stack

[natemcmaster]

cc @Eilon @muratg

[markwilkie]

@natemcmaster wrote a great list to get started. https://gist.github.com/natemcmaster/0ef23512c011b7ec09f25ad13a1d65e2 We should probably create an issue for each item noted and attach it to zenhub.

[natemcmaster]

I've opened some issues on aspnet/BuildTools for things we can do to start moving the needle on this.

• https://github.com/aspnet/BuildTools/issues/727 - change repo layout to match Arcade conventions
• Make (or use) .NET Framework ref assemblies as a nuget package aspnet/BuildTools#399 - Use netfx ref assemblies as a package
• Remove Designer.cs files from source control, generate on the fly aspnet/BuildTools#728 - use resx string generation from Arcade
• Check in the global.json file, use this to control SDK versions aspnet/BuildTools#729 - checkin the global.json file instead of generating it
• Use built-in SDK features for commit hash attributes and source-link aspnet/BuildTools#618 - Use built-in SDK features for commit hash attributes and source-link

[markwilkie]

Thanks @natemcmaster

[natemcmaster]

We've started converting some repos to Arcade. As expected, we've run into lots of little issues. We're not done yet, but I'm going to start filing issues for the ones we think are important.

First up, #1441

[natemcmaster]

#1444

[markwilkie]

@natemcmaster - is this tracking issue (epic) providing any value for you guys? If not, I'll close it....

[natemcmaster]

Today or Monday we are throwing the switch to make the Azure Pipelines build of aspnetcore the official one. That was step 3 of our 4 step plan to converge aspnet with Arcade. This issue represents the last step. Due to my pending paternity leave, I'm not planning to tackle this right away. @Eilon @dougbu might step in to help while I'm out, but if not, this will likely not happen until April or May.

I expect we'll have to open a handful of smaller issues in order to get changes in to Arcade necessary to make AspNetCore work. We could use this as a meta-issue if you want, but I'll let you decide if it's useful. My team doesn't track issues in this repo or use ZenHub.

[natemcmaster]

By the way, here is a list of existing issues that I would say are related to this.

• ASP.NET functional test projects not detected by convention #1646
• Missing [assembly: AssemblyMetadata("Serviceable", "True")] #1526
• Best way to exclude *.sln files? #1525
• Arcade SDK: Run signcheck against all build outputs of real-signed CI #1444
• Support for installing .NET Core shared frameworks #1441
• [TestReporting] [Helix] support reporting test results from jUnit xml format #1485
• global.json: tools.dotnet and sdk.version are redundant #1558
• Too many defaults that are opt-out, and they are different from what MSbuild and the .NET Core SDK chose as defaults #1912
• Project naming changes project behavior #1910

[markwilkie]

Thanks @natemcmaster !

[natemcmaster]

I've also opened dotnet/aspnetcore#7280 on our end to track and assign this work. I'm doing more costing exercises today for other infrastructure efforts, and I think converting to Arcade will be a prerequisite to enabling source-build for aspnetcore.

[natemcmaster]

It's been a long journey, but almost there. This will be resolved with dotnet/aspnetcore#11122