Nuget version not found issue
Is there any cache for nuget sources in csharp?
Version 1.0.7 exists in nuget source, but windmill is unable to find this version, and sometimes it mentions the Nearest version available is 1.0.5, sometimes it mentions 1.0.6, seems very unstable.
Sometimes after a few minutes, windmill is able to find the version 1.0.7 ...
Sometimes, windmill is unable to detect the new version, 10 minutes after that version is available in nuget repo.
BTW, I'm setting NUGET_FEED_URL env var for workers, to use private repo, not sure if it relates to this.
7 Replies
@wendrul @Pyra
Hi @Pyra would you please take a look?
Hi @DigitalMan where exactly are you seeing these warnings? Also are you running this on cloud or self-hosted?
btw you can also provide a nuget.config file by going to Instance Settings > Registries > Nuget Config
When I edit a C# script, which relies on a specific version of a nuget package, like #r "nuget: test.scripts, 1.0.7"
I confirmed that that the version 1.0.7 exists in nuget repo, but when I try to Test, the script is unable to run, says this version not found.
I'm running self-hosted version, with docker
"Settings > Registries > Nuget Config" I guess this is EE only
But even with the NUGET_FEED_URL solution, windmill should provide reliable result?
When it cannot find 1.0.7 version, sometimes it says the nearest version is 1.0.6, sometimes 1.0.5, which is very confusing.
And this has only happened with your package on a private registry correct? Have you tried executing it outside of windmill to confirm it's a windmill issue? the windmill format should be compatible with dotnet-script to easily test it on your machine.
I have been unable to reproduce the issue with public packages, if you have a way to reproduce the issue we would be able to address it
Yes, only happened with my package on private registry.
I have tried outside windmill, for example I can install that version successfully (from the same repo) in Visual Studio.
You cannot reproduce on public repo easily, maybe because most of the packages have been there for a while.
Also that’s not an issue that necessarily occurs every time. No certain pattern. I do not have a reliable way to reproduce as well.
But I believe anyone who updates new versions to private nuget repo frequently, would meet this issue.
I see, it might be that we're not passing in the env variable to the step responsible for dependencies and handling the lock file. Since there's no reproducible way to test it we'll probably just make the change since it's simple and then it might fix your issue.