[binary caching] Failed to push some of the ports to NuGet on Ubuntu

[Pospelove]

UPDATE: Easy way to reproduce is here https://github.com/Pospelove/vcpkg-nuget-issue

Describe the bug
Failed to push some of the ports to NuGet after building (binary caching).

Failed ports:

• boost-regex
• boost-math
• boost-serialization
• mongo-cxx-driver
• sqlite3
• chakracore (overlay port copied from [ChakraCore] Add Linux support #18476)

Pushing boost-regex_x64-linux.1.75.0-vcpkg2150fdca76f992a7b944e55522732509d47ede13.nupkg to 'https://nuget.pkg.github.com/skyrim-multiplayer'...
  PUT https://nuget.pkg.github.com/skyrim-multiplayer/
An error was encountered when fetching 'PUT https://nuget.pkg.github.com/skyrim-multiplayer/'. The request will now be retried.
Error while copying content to a stream.
  Unable to read data from the transport connection: The socket has been shut down.
  The socket has been shut down
  PUT https://nuget.pkg.github.com/skyrim-multiplayer/
An error was encountered when fetching 'PUT https://nuget.pkg.github.com/skyrim-multiplayer/'. The request will now be retried.
Error while copying content to a stream.
  Unable to read data from the transport connection: The socket has been shut down.
  The socket has been shut down
  PUT https://nuget.pkg.github.com/skyrim-multiplayer/
An error occurred while sending the request.
  The server returned an invalid or unrecognized response.
Pushing NuGet to GitHub failed. Use --debug for more information.

Environment

• OS: Ubuntu latest (GitHub Actions)
• Compiler: Clang 11
• vcpkg 3c82e19

To Reproduce
Trigger .github/workflows/cmake.yml for skyrim-multiplayer/skymp#85 (last commit hash - 58812850911e8e1488b73be033a0a5d61a7bf551)

Expected behavior
Everything should be pushed to NuGet successfully.

Failure logs
https://github.com/skyrim-multiplayer/skymp/runs/3121332869?check_suite_focus=true

See also
NuGet/Home#8580

[Neumann-A]

Do you have more than one NuGet binary cache for vcpkg on Github?

[Pospelove]

Do you have more than one NuGet binary cache for vcpkg on Github?

No.

[JackBoosY]

Maybe related to #15289.

[Pospelove]

Maybe related to #15289.

@JackBoosY I can create a sample repo with a minimal reproducible example if it helps.

[JackBoosY]

@Pospelove Yes please.

[Hoikas]

This is the same issue I mentioned to @ras0219-msft in discord a few months ago. I saw it with the physx and python3 ports on macOS and Linux.

[Pospelove]

@JackBoosY

It's finally out:
https://github.com/Pospelove/vcpkg-nuget-issue

This is a very minimal repo. The only things it contains are vcpkg submodule, manifest, and a workflow file.
See readme.

It's based on GitHub Actions because of the original example. Please let me know if you need to reproduce this bug locally instead of using GitHub Actions.

[m-kuhn]

gdal is also affected

[m-kuhn]

gdal is also affected

This seems to be a different issue #19189

[PhoebeHui]

Related to NuGet/Home#8580 and NuGet/Home#10045.

It seems nuget issue on ubuntu, I'm not sure what should vcpkg do here, update the docs? @ras0219-msft @ras0219, could you please take a look?

[Pospelove]

Any progress on this?

[Pospelove]

[JackBoosY]

@BillyONeal Any ideas?

[BillyONeal]

Nope. We're invoking NuGet and NuGet is failing. Not much we can do I think

[Pospelove]

Anyway thanks for taking a look, let's keep this issue open for now

[SchaichAlonso]

You need to setup an api key explicitly by running something like

  nuget setapikey "${{ secrets.GITHUB_TOKEN }}" -source "https://nuget.pkg.github.com/${{ github.repository_owner }}/index.json"

The example provided in the documentation on nuget binary caching has already been updated.

[Pospelove]

You need to setup an api key explicitly by running something like

  nuget setapikey "${{ secrets.GITHUB_TOKEN }}" -source "https://nuget.pkg.github.com/${{ github.repository_owner }}/index.json"

The example provided in the documentation on nuget binary caching has already been updated.

Thank you for your tip. I'm not working on binary caching in any of my projects atm, so I'll close this issue. I'll reopen this in case of being able to reproduce the original bug.