Граф коммитов

7 Коммитов

Автор SHA1 Сообщение Дата
Serge Mera 61a3155c57 Merged PR 663349: Reapply NuGet resolver changes and deal with interactive auth
Reverting the revert, plus handling interactive auth for local builds:
* build.cmd 'primes' the auth token cache by launching the specified cred provider (for internal+interactive builds)
* The cred provider used by bxl is allowed to read/write to the auth token cache. This implies dealing with the IsRetry pattern.

I'll have somebody (besides me) check that the local case works before merging.
2022-05-25 18:50:57 +00:00
Serge Mera dc0568ae3f Merged PR 663100: Revert nuget resolver changes and set LKG to 0.1.0-20220519.2 2022-05-23 19:22:28 +00:00
Serge Mera cedafaec0e Merged PR 662608: Reapply NuGet resolver schedules real pips
Same commit as before plus:
* Force check the nuget package fp on disk (apparently this was off by default because dotnet core didn't support nuget at that time) (that should fix the DFA we saw, which is a layout difference between a public vs internal package when an agent gets reused)
* Capture stderr when executing the cred provider, for better error diagnostics.

From the issues we saw, there is still one that I was not able to repro (https://dev.azure.com/mseng/Domino/_build/results?buildId=17296398&view=logs&j=cfa20e98-6997-523c-4233-f0a7302c929f&t=144c797d-20c9-5763-9672-cca1a82cd366). I'll keep trying, but the stderr should be able to tell us more if that happens again. Hopefully we can spot this before I merge this.
2022-05-20 17:27:12 +00:00
Michael Pysson 4e9cff438c Merged PR 662122: Revert "Merged PR 661589: Reapply: nuget resolver schedules real pips"
Revert "Merged PR 661589: Reapply: nuget resolver schedules real pips"

This reverts commit 53d8270164.

This change is still causing some breaks in downstream validation
2022-05-16 21:09:46 +00:00
Serge Mera 53d8270164 Merged PR 661589: Reapply: nuget resolver schedules real pips
Reverting the revert to merge the original PR: eebb9c136a?refName=refs%2Fheads%2Fdev%2Fsmera%2Frelease509.1.1

Plus, a couple minor tweaks to make this work for linux and mac. Those changes are grouped in a separate commits so they are easier to spot.

In parallel I'm working on the rolling build cred provider configuration changes so this PR can pass.
2022-05-12 20:38:35 +00:00
Iman Narasamdya 1cc3607a86 Merged PR 660987: Revert "Merged PR 659816: Nuget resolver schedules real pips
Revert "Merged PR 659816: Nuget resolver schedules real pips

Purpose: to unblock rolling builds.

This PR changes the NuGet resolver logic so instead of downloading packages at evaluation time, download pips are scheduled so the package download and extraction happens as part of the build. The high-level flow is the following:
- The nuget resolver downloads enough of each NuGet package just to understand its layout (usually <5k) + the nuspec file. This is taking ~10s on my machine. The inspection process is still using the local + bxl cache caching layer, in the same way the fully downloaded packages were using before. So hits are also possible.
- The spec generation process now generates calls into the (internal) nuget downloader SDK. The specs are still generated on disk. We can consider doing this in memory (as other resolvers do), but that can be left for a second iteration.
- A new nuget downloader tool is now deployed as part of bxl binaries, with a small DScript SDK that schedules it. The generated specs use it. Nuget.exe is not used anymore, the nuget api is used instead. This makes the whole process less prone to machine-depending state that nuget.exe reads by default and doesn't allow us to block.

Related work items: #1942615"

Reverted commit `eebb9c13`.

Related work items: #1942615
2022-05-06 22:27:59 +00:00
Serge Mera eebb9c136a Merged PR 659816: Nuget resolver schedules real pips
This PR changes the NuGet resolver logic so instead of downloading packages at evaluation time, download pips are scheduled so the package download and extraction happens as part of the build. The high-level flow is the following:
- The nuget resolver downloads enough of each NuGet package just to understand its layout (usually <5k) + the nuspec file. This is taking ~10s on my machine. The inspection process is still using the local + bxl cache caching layer, in the same way the fully downloaded packages were using before. So hits are also possible.
- The spec generation process now generates calls into the (internal) nuget downloader SDK. The specs are still generated on disk. We can consider doing this in memory (as other resolvers do), but that can be left for a second iteration.
- A new nuget downloader tool is now deployed as part of bxl binaries, with a small DScript SDK that schedules it. The generated specs use it. Nuget.exe is not used anymore, the nuget api is used instead. This makes the whole process less prone to machine-depending state that nuget.exe reads by default and doesn't allow us to block.

Related work items: #1942615
2022-05-05 19:02:49 +00:00