-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
Comments
Hi @PazerOP Have you tried the suggestion here microsoft/vcpkg-tool#40 (comment)? Please let us know if this can work for you. Thanks. |
I have the same problem. But I think it would be better if it was possible to cache the same packages from different repositories. but X_VCPKG_NUGET_ID_PREFIX work for me. And solve 'Package "xxx" is already associated with another repository.'. |
One more things - X_VCPKG_NUGET_ID_PREFIX don't working for download cached package. -( Build is working, but it's slow. |
can we hope to handle X_VCPKG_NUGET_ID_PREFIX when searching the cache? |
@ctapmex Since this issue was resolved, can you please open a new issue to request that? |
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
To Reproduce
Steps to reproduce the behavior:
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
):The text was updated successfully, but these errors were encountered: