Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub Packages broken with multiple repos in 1 org #16579

Closed
PazerOP opened this issue Mar 7, 2021 · 5 comments
Closed

GitHub Packages broken with multiple repos in 1 org #16579

PazerOP opened this issue Mar 7, 2021 · 5 comments
Assignees
Labels
category:vcpkg-feature The issue is a new capability of the tool that doesn’t already exist and we haven’t committed

Comments

@PazerOP
Copy link
Contributor

PazerOP commented Mar 7, 2021

Describe the bug
Attempting to use github packages integration, with the same package(s), from two separate repositories within the same organization will cause package upload failures.

I set up GitHub Packages + binarycaching with GitHub actions in one of my repos (https://github.com/PazerOP?tab=packages&repo_name=stuff), and was very happy with how it worked. I then tried to integrate it with another repo (https://github.com/PazerOP?tab=packages&repo_name=SourceRCON). After setting it up with the second repo, I noticed that fmt_x64-linux was failing to upload to GitHub Packages. It appears this is an issue because fmt_x64-linux is associated with the first repo (PazerOP/stuff), and will not accept new versions uploaded from a second repo.

Environment

  • OS: ubuntu, but probably doesn't matter what OS
  • Compiler: GCC 9, but also probably doesn't matter

To Reproduce
Steps to reproduce the behavior:

  1. Set up vcpkg with GitHub Packages binarycaching on repo A, and install a package.
  2. Set up vcpkg with GitHub Packages binarycaching on repo B, and install the same package. Make sure your build flags/compiler version/etc are different, such that the cached package from repo A is not suitable for use in repo B (aka make sure there is a cache miss).
  3. The upload of the package from repo B to GitHub Packages will fail.

Expected behavior
The package from repo B should be successfully cached, one way or another. I don't (personally) care about the advertised feature of the GitHub Packages cache being shared between repos. All that matters to me is that they are cached so a particular repo will not do a complete rebuild on each CI run. A bandaid solution might be to just have a command line option for vcpkg that lets me specify a user-defined prefix or suffix for the NuGet packages.

Failure logs
Log from the second repo (with --debug):

Starting package 3/4: fmt:x64-linux
Building package fmt[core]:x64-linux...
[DEBUG] popen(/home/runner/work/SourceRCON/SourceRCON/vcpkg/downloads/tools/cmake-3.19.2-linux/cmake-3.19.2-Linux-x86_64/bin/cmake -DALL_FEATURES= -DCURRENT_PORT_DIR=/home/runner/work/SourceRCON/SourceRCON/vcpkg/ports/fmt -D_HOST_TRIPLET=x64-linux -DFEATURES=core -DPORT=fmt -DVCPKG_USE_HEAD_VERSION=0 -D_VCPKG_DOWNLOAD_TOOL=BUILT_IN -D_VCPKG_EDITABLE=0 -D_VCPKG_NO_DOWNLOADS=0 -DCMD=BUILD -DDOWNLOADS=/home/runner/work/SourceRCON/SourceRCON/vcpkg/downloads -DTARGET_TRIPLET=x64-linux -DTARGET_TRIPLET_FILE=/home/runner/work/SourceRCON/SourceRCON/vcpkg/triplets/x64-linux.cmake -DVCPKG_BASE_VERSION=2021-01-13 -DVCPKG_CONCURRENCY=3 -DVCPKG_PLATFORM_TOOLSET=external -DGIT=/usr/bin/git "-DVCPKG_PORT_CONFIGS=/home/runner/work/SourceRCON/SourceRCON/cmake_out/vcpkg_installed/x64-linux/share/vcpkg-cmake/vcpkg-port-config.cmake;/home/runner/work/SourceRCON/SourceRCON/cmake_out/vcpkg_installed/x64-linux/share/vcpkg-cmake-config/vcpkg-port-config.cmake" -DVCPKG_ROOT_DIR=/home/runner/work/SourceRCON/SourceRCON/vcpkg -DPACKAGES_DIR=/home/runner/work/SourceRCON/SourceRCON/vcpkg/packages -DBUILDTREES_DIR=/home/runner/work/SourceRCON/SourceRCON/vcpkg/buildtrees -D_VCPKG_INSTALLED_DIR=/home/runner/work/SourceRCON/SourceRCON/cmake_out/vcpkg_installed -DDOWNLOADS=/home/runner/work/SourceRCON/SourceRCON/vcpkg/downloads -DVCPKG_MANIFEST_INSTALL=OFF -P /home/runner/work/SourceRCON/SourceRCON/vcpkg/scripts/ports.cmake 2>&1)
-- Using cached /home/runner/work/SourceRCON/SourceRCON/vcpkg/downloads/fmtlib-fmt-7bdf0628b1276379886c7f6dda2cef2b3b374f0b.tar.gz
-- Cleaning sources at /home/runner/work/SourceRCON/SourceRCON/vcpkg/buildtrees/fmt/src/2b3b374f0b-8ea71ee8ea.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source /home/runner/work/SourceRCON/SourceRCON/vcpkg/downloads/fmtlib-fmt-7bdf0628b1276379886c7f6dda2cef2b3b374f0b.tar.gz
-- Applying patch fix-warning4189.patch
-- Using source at /home/runner/work/SourceRCON/SourceRCON/vcpkg/buildtrees/fmt/src/2b3b374f0b-8ea71ee8ea.clean
-- Configuring x64-linux-dbg
-- Configuring x64-linux-rel
-- Building x64-linux-dbg
-- Building x64-linux-rel
-- Installing: /home/runner/work/SourceRCON/SourceRCON/vcpkg/packages/fmt_x64-linux/share/fmt/copyright
-- Fixing pkgconfig file: /home/runner/work/SourceRCON/SourceRCON/vcpkg/packages/fmt_x64-linux/lib/pkgconfig/fmt.pc
-- Fixing pkgconfig file: /home/runner/work/SourceRCON/SourceRCON/vcpkg/packages/fmt_x64-linux/debug/lib/pkgconfig/fmt.pc
-- Installing: /home/runner/work/SourceRCON/SourceRCON/vcpkg/packages/fmt_x64-linux/share/fmt/usage
[DEBUG] cmd_execute_and_stream_data() returned 0 after 11062321 us
-- Performing post-build validation
-- Performing post-build validation done
[DEBUG] popen(/usr/bin/mono /home/runner/work/SourceRCON/SourceRCON/vcpkg/downloads/tools/nuget-5.5.1-linux/nuget.exe pack /home/runner/work/SourceRCON/SourceRCON/vcpkg/buildtrees/fmt/x64-linux.nuspec -OutputDirectory /home/runner/work/SourceRCON/SourceRCON/vcpkg/buildtrees -NoDefaultExcludes -ForceEnglishOutput -NonInteractive 2>&1)
[DEBUG] cmd_execute_and_stream_data() returned 0 after  1269476 us
Attempting to build package from 'x64-linux.nuspec'.
Successfully created package '/home/runner/work/SourceRCON/SourceRCON/vcpkg/buildtrees/fmt_x64-linux.7.1.3-vcpkg9cbe796a59b5d4b0f74b5af284208f1a59ded4f6.nupkg'.
WARNING: NU5103: The folder 'lib/pkgconfig/fmt.pc' under 'lib' is not recognized as a valid framework name or a supported culture identifier. Rename it to a valid framework name or culture identifier.
WARNING: NU5128: Some target frameworks declared in the dependencies group of the nuspec and the lib/ref folder do not have exact matches in the other location. Consult the list of actions below:
- Add a dependency group for pkgconfig0.0 to the nuspec
Uploading binaries for fmt:x64-linux to NuGet source GitHub.
[DEBUG] popen(/usr/bin/mono /home/runner/work/SourceRCON/SourceRCON/vcpkg/downloads/tools/nuget-5.5.1-linux/nuget.exe push /home/runner/work/SourceRCON/SourceRCON/vcpkg/buildtrees/fmt_x64-linux.7.1.3-vcpkg9cbe796a59b5d4b0f74b5af284208f1a59ded4f6.nupkg -ForceEnglishOutput -Source GitHub -NonInteractive 2>&1)
[DEBUG] cmd_execute_and_stream_data() returned 256 after  1615940 us
WARNING: No API Key was provided and no API Key could be found for 'https://nuget.pkg.github.com/PazerOP'. To save an API Key for a source use the 'setApiKey' command.
Pushing fmt_x64-linux.7.1.3-vcpkg9cbe796a59b5d4b0f74b5af284208f1a59ded4f6.nupkg to 'https://nuget.pkg.github.com/PazerOP'...
  PUT https://nuget.pkg.github.com/PazerOP/
WARNING: Package "fmt_x64-linux" is already associated with another repository.
  UnprocessableEntity https://nuget.pkg.github.com/PazerOP/ 682ms
Response status code does not indicate success: 422 (Unprocessable Entity).
Pushing NuGet to GitHub failed. Use --debug for more information.
@PhoebeHui PhoebeHui added the category:vcpkg-feature The issue is a new capability of the tool that doesn’t already exist and we haven’t committed label Mar 8, 2021
@NancyLi1013
Copy link
Contributor

NancyLi1013 commented Apr 26, 2021

Hi @PazerOP

Have you tried the suggestion here microsoft/vcpkg-tool#40 (comment)? Please let us know if this can work for you.

Thanks.

@ctapmex
Copy link

ctapmex commented May 22, 2021

I have the same problem. But I think it would be better if it was possible to cache the same packages from different repositories.
For example, there is one organization with two repositories. They depend on the same external libraries. In one repository, CI works once a day, in the second - once every 2 weeks. If you use X_VCPKG_NUGET_ID_PREFIX (or without it, when the first repository is the owner of all packages), then each build will go slowly - there is no cache (the images for the build change often https://github.com/actions/virtual-environments/tree/main/images).

but X_VCPKG_NUGET_ID_PREFIX work for me. And solve 'Package "xxx" is already associated with another repository.'.
Thanks

@ctapmex
Copy link

ctapmex commented Jun 14, 2021

One more things - X_VCPKG_NUGET_ID_PREFIX don't working for download cached package. -( Build is working, but it's slow.

@ctapmex
Copy link

ctapmex commented Jul 22, 2021

can we hope to handle X_VCPKG_NUGET_ID_PREFIX when searching the cache?

@JackBoosY
Copy link
Contributor

@ctapmex Since this issue was resolved, can you please open a new issue to request that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:vcpkg-feature The issue is a new capability of the tool that doesn’t already exist and we haven’t committed
Projects
None yet
Development

No branches or pull requests

6 participants