Hi @marc-ledent_9164, There's really just one, and that's the artifacts (BuildMaster) or packages (ProGet). To configure server level shared storage, you'll want to configure: For BuildMaster, the Artifacts.BasePath value in Administration > Advanced Settings. For ProGet, the Storage.PackagesRootPath value in Administration > Advanced Settings. Do note that ProGet also allows configuration of storage at a feed level, which you can find on the Manage Feed page for each feed. Click change on the right side of the Disk Path property. This guide might be helpful: https://docs.inedo.com/docs/installation-high-availability-load-balancing

Hi @pegogif654_4423, We have some great blog posts about this for NuGet and you can apply the same concepts to UPACK and Docker. 5 Quick Tips for NuGet Versioning How to use CI/CD pipelines for your NuGet Packages I believe you are looking to use our Repackaging feature and Package Promotion. Please note that in free editions of ProGet, you can only use the ProGet UI to repackage (for Docker it is Add Virtual Tag) and promote packages and containers. The APIs require a paid edition. Hope this helps! Thanks, Dan

Hi @marc-ledent_9164, Thanks for letting us know this is now resolved. Thanks, Dan

Thanks a lot

We found the problem finally, we had to enable this option [image: 1652731085537-microsoftteams-image.png]

@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

@atripp Hi hello after downloading scripting 2.01 i restart the server otter worked perfectly. thanks

@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.

Hi @zakaria-smahi_2127, That badge looks like something generated by a CI-server, and I think it's showing the latest version or tag or something related to a release branch? I don't have much context. It's not something that ProGet (a package manager) would generate, since all of the packages in ProGet are considered "published". Our CI/CD platform, BuildMaster, can generate these badges: https://docs.inedo.com/docs/buildmaster-ci-cd-continuous-integration-server-badges Cheers, Alana

Hi @gurdip-sira_1271, Just to let you know, Otter v2022 has been released; from here it'd be best to start a new thread if you have a specific issue -- we'll be happy to help! Steve

Hi @fabian_7019, Thanks for bringing this to our attention. I was able to recreate the error and we will get this fixed in the next version of Otter, 3.0.25, which is due out next Friday. This looks to only be an issue when there is only one raft repository setup in Otter. As a workaround, if you create a second raft repository under Administration -> Raft Repositories, you will then be able to create new folders in the default raft. The fix is being tracked in ticket OT-461. Thanks, Rich

@atripp Thanks for the pointers. Investigations did indeed reveal that proget was replying with the http url if FindPackagesById() request and that the subsequent redirect back to https was causing the credential to be dropped from the request. I've configured the BaseUrl with advanced settings and confirmed success with that in place. I now have a functioning proget instance and I'm able to efficiently work with the repo from Powershell. Much appreciated!

Hi @mcascone , I think that was a feature that got lost in 5.3, with the new UI. Easy enough to bring back, I think, so we'll add it via PG-2134 Cheers, Alana

@atripp Thanks, I was able to enable the v3 api for my feed. Just in case anyone else stumbles on this the v3 api url was actually https://MY.FQDN/nuget/MYNUGETFEED/v3/index.json. Visual Studio does correctly hide the unlisted versions using the v3 api, thank you.

Hello dean-houston, thank you very much for your answer. I have been able to solve the problem with our network team. The networkers had to make one more setting in the proxy. thx

Thank you, in my case this is an internal Nuget package that is deployed directly to Proget. I unlisted a package version in Proget and I see the listed property is false via fiddler but it still shows up in a visual studio search. By the way, I just created a new topic for my issue here. https://forums.inedo.com/topic/3514/unlisted-package-version-still-shows-up-in-visual-studio

@nkumari_3548 you'll likely want to check with your network team for help on this one ProGet is a standard web application, and will listen for all traffic on the port you've configured. If you want to access ProGet with proget.my-company.corp, then you'll need to have someone configure appropriate domain/DNS records, etc. You may also need firewall settings, and a certificate for HTTPS. https://proget.inedo.com/ is our public instance of ProGet. It's not intended for direct access by users, but by tools like docker or Inedo Hub. You can't login to it.

Just as a follow-up on the solution. This error came from a Git Repository Monitor. The Docker Image for Build Master does not include git installed out of the box. This will require you to either install git on the running container or use a BuildMaster Agent/SSH server to be added and to run this on there. The other issue was that the repository monitor was using a secure resource from a specific application, so the repository monitor needs to specify the application it uses as well.

OK, I got it. the servers are the ssh servers tha BM is connecting to while deploying. As this is a test env, there are a lot of faulty servers Thanks for the help, Marc

Thanks, yeah, that seems to work. I changed my pipeline code to not send any title metadata to ProGet, which returned that field in the UI to its original behavior. I also found that rebuilding an existing package, and sent to ProGet with the updated pipeline, has the same effect.