Arcade: Help Nuget.Client to get their build published using the new infra

[JohnTortugo]

I'll use this issue to track my assistance to the NuGet folks to get the NuGet.Client repo onboard with latest Arcade publishing infra.

/cc @zivkan @mmitche @riarenas

[JohnTortugo]

@zivkan - I think the first step here, for a long term solution, should be for NuGet.Client to start using the Arcade.SDK. The SDK prepares everything to be read for shipping, including signing and some asset validations. However, If for some reason that's not an option, I can help you to get your custom publishing infrastructure to match the requirements of the Maestro publishing infra.

Here is some documentation about getting onboard with Arcade SDK:

• https://github.com/dotnet/arcade/blob/master/Documentation/Onboarding.md
• https://github.com/dotnet/arcade/blob/master/Documentation/ArcadeSdk.md

If you have any question please ping us here or feel free to ping me directly on Teams.

[markwilkie]

I 2nd Cesar's (johntortugo) recommend to use Arcade. It'll save the work of "keeping up" with the rest of the infrastructure and relieve much of the overhead from your team.

[zivkan]

I like the idea of using Arcade, but I fear it's going to be a lot of work and take multiple sprints to complete. We need to be able to do insertions before then.

As an interim, we could create the PRs ourselves, the only thing we need to know how to do is generate the right hash used in Version.Details.xml. Before we ever used darc, we already had scripts to automatically update Versions.props in the right branches or the right repos. We can resurrect this script and improve it to make the relevant changes to Version.Details.xml as well, although once you have the package version and the hash, it wasn't too much work to create the PRs manually.

At the beginning of February, I talked to Matt Galbraith and Chris Costa about .NET Engineering in general, but the impression I came away with is that it's not possible to incrementally move towards arcade. It feels like it's (almost) all or nothing. There were also at least 2 things we weren't sure if could be fulfilled.

Here's a list of my concerns, while I'll update as the discussion progresses, to keep the latest information in one place. Please let me know what you think we should do in the short term to unblock insertions.

• [ ] Does Arcade use AzDO tasks that do not exist outside the dnceng AzDO tenent, or does it provide scripts around tasks that also exist in DevDiv? In other words, how mandatory is it to move to the dnceng AzDO tenent, from DevDiv? If we can avoid that, then most of my concerns below disappear, as we can be more incremental.
  
  
  
  • [ ] What does the transition look like? Can a NuGet build be added to dnceng that only runs on one branch while we keep building in DevDiv?
  
  
• [ ] We get our build number from a text file that we increment every build. Yes, there's a potential problem if two builds run this step at the same time, but it hasn't been a problem yet. We need to improve this anyway, but since it's never caused a problem, it hasn't yet been worth the engineering effort.
• [ ] final artefact location. Currently, our builds are written to a network share, meaning our builds run on agents on corpnet. This also needs to change regardless, but hasn't yet.
  
  
  
  • [ ] Our manual test vendors install the NuGet VSIX from this location, so we'd have to provide them some way of getting the binaries to test. Although I'm sure that dotnet has manual testing, suggesting that the binaries are available to testers somehow.
  
  
  • [ ] Our VS insertion scripts use this location. Depending on where arcade saves artefacts, we might be able to adapt our existing scripts, otherwise we'll need support. When I talked to Matt and Chris, they said this was a topic that was blocking Roslyn from moving to dnceng as well. Was this solved now? How does project-system insert into VS?
  
  
• [ ] Automated VS testing. NuGet has two tests "jobs" (previously called phases) that run on custom agents where we install NuGet's VSIX and run automated GUI tests (some Apex tests, some tests that I think are scripted through powershell and DTE). I don't remember the outcome of this discussion with Matt and Chris, but I think I remember them saying that Roslyn also do tests that install their VSIX into VS, but I can't remember if that was their own infrastructure, or provided by .NET Engineering.
• [ ] Cost centres. This is just administrative, but it might slow down the migration. NuGet isn't under joc's org, we're under Doug. I was told this means we need something separate so that the different budgets can be billed correctly, but maybe this was just for testing with Helix, rather than the builds themselves. The good news is that the XAML experiences team is already set up, and we share the same M2, so we can probably piggy-back off their cost centre code.
• [ ] ArcadeSdk output. The onboarding docs linked show a sample of the build output structure. NuGet already uses something similar, but not the same. I don't know how important it is to use exactly the structure listed. If it's mandatory, that increases the cost of migrating.
• [ ] build/restore/test scripts. If we're required to do this up-front, it will increase the cost of migration, particularly since it doesn't fit well with NuGet's current scripts. We have some tests (for mono) that only run on Mac. To reduce build time, on Windows we run tests on 3 machines in parallel, each running different tests. I don't know how this fits with a single test.cmd script.

[markwilkie]

Makes sense @zivkan. Maybe the right next step is to have a video chat w/ at least me, @JohnTortugo , @riarenas, and @mmitche? We can then go through your excellent list (and update our docs to have answers for the next person) and agree on the right path forward.

Basically - let's find the right thing and do it. :)

[JohnTortugo]

[ ] Does Arcade use AzDO tasks that do not exist outside the dnceng AzDO tenent, or does it provide scripts around tasks that also exist in DevDiv? In other words, how mandatory is it to move to the dnceng AzDO tenent, from DevDiv? If we can avoid that, then most of my concerns below disappear, as we can be more incremental.

I might be quite wrong but I don't think the Arcade.SDK have strong requirements on the build being on DncEng. There are a couple of repos building from DevDiv that uses the SDK.

[zivkan]

Thanks everyone for the meeting yesterday. Brief summary is that arcade is a set of components that can be used in either dnceng or devdiv. So, there's no reason why we can't keep using the same build and test scripts, same agent machines, same CI yaml, and just change one thing at a time. Cesar's going to help me do the minimum to get the artifacts and manifest publishing via the arcade SDK, once something has been published into the devdiv AzDO tenent. Then I can work with Ricardo to better understand arcade to see what else makes sense to use in the short term.

From my looking around, it seems to me that Cesar will be helping me getting this publishing infrastructure, working, right? And this folder contains the list of build tasks I could use in my yaml?

[JohnTortugo]

@zivkan - The main steps here seems to be this:

• Update the version of Tasks.Feed package used in your infra to the most recent one. I believe the update should go here. Same for Maestro.Tasks.
• Follow this step of the documentation to get your custom publishing infra using the new publish task (PushToAzureDevOpsArtifacts instead of PushToBlobFeed).
• Follow the step described here to configure Maestro to publish packages produced from your test branch to the General Testing channel.
• After that you should be able to run an internal test build from your branch and let's see if all assets go to the testing feeds.

[zivkan]

@JohnTortugo the link you posted in the 3rd point, to configure Maestro for the general testing channel, doesn't work.

[JohnTortugo]

Fixed it.

[zivkan]

The docs on migrating from PushToBlobFeed to PushToAzureDevOpsArtifacts show both tasks using a propery named PublishFlatContainer. However, NuGet never used this property. Do I need to start using it? If so, where do I get the value? From the feed url's service index?

Also, do I keep the PushMetadataToBuildAssetRegistry task? From our meeting last week, I thought that someone said that the new task published the manifest automatically, but your instructions didn't say anything, so I'm not sure.

[JohnTortugo]

The docs on migrating from PushToBlobFeed to PushToAzureDevOpsArtifacts show both tasks using a propery named PublishFlatContainer. However, NuGet never used this property. Do I need to start using it? If so, where do I get the value? From the feed url's service index?

If you didn't previously then it was using the default, which was/is false.

Also, do I keep the PushMetadataToBuildAssetRegistry task? From our meeting last week, I thought that someone said that the new task published the manifest automatically, but your instructions didn't say anything, so I'm not sure.

You should keep that. This task persist information in the Maestro database (BAR). The other task just update your build manifest to Azure DevOps Artifacts.

[zivkan]

I've just about got it working, but I'm getting assembly load errors:

error : FileNotFoundException: Could not load file or assembly 'System.Security.Permissions, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.

https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=3562124&view=logs&j=8460ae35-dae7-5d3d-b89d-5bc71d24ad43&t=bff6d458-b913-5a1d-6151-4dcb2342e42a&l=24

Any suggestions?

edit: Just realised I'm using the netfx compiled tasks. Trying again with the netcoreapp tasks.

[zivkan]

It worked! PR created

[JohnTortugo]

I posted some comments in the PR.

[zivkan]

The PR has been merged now. This issue can be closed (I don't have permission).

[markwilkie]

Thanks @zivkan !