@dean-houston Thank you for the insight! Definitely did not think of that as an issue.

@kichikawa_2913 we don't have a typical set-up per se, really A lot of set-ups are very simple, since the team is new to CI/CD, and they just have the BuildMaster server do everything. Others have dozens of build agents configured in a pool to service various teams, and use lots of shared configuration. Most are somewhere in the middle -- since they started simple, and gradually explored over time. That's generally what i'd start with -- tackle one pattern/team, then move on to the next and improve over time.

@kichikawa_2913 thanks for letting me know; well, if you see it come again, please do inform us. It may be a caching issue on Linux/containers, but hard to say

Hi @bbrown2_8761 , It's a bug in Visual Studio's NuGet client I'm afraid and it's not something we can realistically work-around You could post it in the NuGet issues, and they may fix it in a future version; https://github.com/NuGet/Home/issues It's really easy to reproduce, and they've definitely fixed issues like this in the past. Cheers, Alana

Hi @kichikawa_2913, Could you please open another topic for the Selenium.WebDriver.ChromeDriver issue? I think that is unrelated to the authentication issue. Thanks, Rich

Hi @kichikawa_2913, Good catch! It looks like this is missing from our documentation. I'll work to get it updated this week! Thanks, Dan

Hi @kichikawa_2913, Thanks for following up and letting us know that you found the solution! Thanks, Dan

@stevedennis sorry for such a delayed reply. Our use case is simply because when we setup our shares on our SAN we setup a share per package type (python, NuGet, etc) just in case of the need to more granularly control backups/maintenance of the shares. We may run into different issues/needs depending on the package type or we may not, just wanted to have the ability.

I thought I did have anonymous View/Download on that feed, I did not. It's working now with the Api Key I set under administration, thank you!

Hi @kichikawa_2913, Sorry, this is actually expected. When we release our products, they include the extensions that were released at the time of the product release. In this case, I released this version of InedoCore after we did the product release. If you look at our documentation for upgrading your docker image, the command includes --volumes-from=proget-old. This will auto migrate the previous volumes created from the previous version of ProGet and that will keep the updated extension (as long as the previous extensions is newer than the included extension version). Also, in Administration -> Advanced Settings, you can change Extensions.ExtensionsPath to a mapped path and that will also do the same thing (if the version in this directory is newer than the included) and give you easier access to the extension files. Thanks, Rich

@rhessinger Thank you!