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

Hi Igor, Thanks for the help in tracking this down. We've now fixed this in an internal build (logged as OT-428) . The fix will be in Otter v3.0.12, scheduled for release on October 8. If you'd like to test a prerelease build, you can pull the proget.inedo.com/productimages/inedo/otter:3.0.12-ci.1 image, which already contains the fix. -Greg

@mcascone do you happen to remember where you found that link? We are trying to be conservative about adding a ton of redirect rules... We are now running automated scans, so HOPEFULLY it's picking up bad links within the docs.

Hi @Stephen-Schaff , Yes, this can be a little bothersome. Actually this is something that we're considering for v6, to mostly replace the "impersonation" feature: Allow on Feeds: [feed1, feed2, «group1»] Feed Permission: View/Download Publish/Push Delete/Overwrite The "username" would still be there, but mostly for "personal api keys". Thanks, Alana

Hello; I'm not all that familiar with Ruby Gems, but I'll try to help. At first, I think the problem is that you're using host instead of source. gem push <gem file> --source http://<redacted>/rubygems/RubyGem Hope that does the trick :) FYI; we recently updated our RubyGems Documentation to help others get setup.

Thanks @antony-booth_1029 ! This should get fixed via BM-3740 in the next maintenance release of BuildMaster

It seems the package deployment endpoint is POST-only, but using the Native API you could use the Packages_GetPackageDeployments method. Down the line we can certainly consider adding GET method on the deployment api... if you can help us know what you/someone will use that info for ;)

@Dan_Woolf I got it fixed by changing some permissions. Somehow even though Admin had rights to the feed it would not show up. I removed admin and added Administrators now all is good. Thank you for your help!

Hi @Fauzi-Ashurex_3595, I see you have submitted a formal support ticket for this. I will post back the final solution to this post once it is fixed. Thanks, Dan

@grant-sparks_1282 I'm surprised there's no index, but I guess that's a property popular repository, so we can make ProGet not error in this case. i logged PG-2007 to handle this :)

@mcascone yep, that's a good way of putting it!

Ah, that makes sense, the weirdness of the NuGet Gallery is why we're migrating to ProGet in the first place Anyway, thanks for the great support. Will definitely recommend ProGet in the future!

Hi @brett-polivka, I haven't tried ghcr, but in my experience GitHub is really unstable on the API/integration side when it's outside of their core source/Git hosting functions (e.g. Packages are notoriously buggy), so if your PAT is okay, then this is the most likely scenario. The Connector Health Check for Docker uses the catalog API (/v2/_catalog), and the response should look something like this: https://proget.inedo.com/v2/_catalog. This endpoint is particularly buggy in other repositories (especially ones that require authentication/authorization), so my guess is GitHub introduced a regression or something on their implementation. Another possibility... 403 is access related, so it could be something on your proxy side; please also check your Proxy settings, or something on your network side.

Hi @grant-sparks_1282, Thank you for the very detailed information in sharing the problem and reproduction instructions. Based on this, I'm convinced you've run into this issue: PG-2005 (POM files downloaded from Maven feeds may be saved with empty contents). ProGet 5.3.37 (which has that fix) is scheduled to be fixed on Friday, but we may release it sooner given the impact. It's holiday in US, otherwise we likely would have done it today already Anyways, you have two choices: [Recommended] Upgrade to ProGet 5.3.37-rc.2; for the Inedo Hub installation, you just need to switch to the Prerelease Feed Downgrade to ProGet 5.3.34 The only difference between 5.3.36 and 5.3.37-rc.2 is that single issue (PG-2005). Cheers, Alana

@atripp thanks, that worked to prompt for the login

@arozanski_1087 that's a slightly different caching setting If you navigate Feeds > Connectors >your conenctor, it will be here: [image: 1630687457379-c8f90f17-7cae-4e96-b777-d934f1ee96ce-image.png] Clicking on 'status" will show you all the cached queries.

@antony-booth_1029 thanks for the update! Anecdotally, I've heard of similar issues with AWS RDS. I understand that, behind the scenes, it's some large/shared SQL Server database installation, so I wonder if other traffic impacts it? We've certainly confirmed that was the case in some organizations with their own large SQL Server cluster. You may find using SQL Server Express + Self Backup is okay enough, too.

We have a lot of customers who maintain a separate test instance of ProGet; while upgrade testing is important of course, a dedicated testing instance also lets you evaluate new ProGet feature usage patterns (such as requiring promotion workflows, etc.), try out new tools (perhaps new version of visual studio, etc.), and conduct training on ProGet usage -- all without risking/disturbing your production instance. To keep things simple from a licensing perspective, we just treat testing instances separate instances (and thus require a separate license key). Many customers use a ProGet Free License for this, but of course not all the features are available. It's rare to see a second license be cost prohibitive, especially given the labor/server costs involved with maintaining a testing instance -- even ProGet Enterprise customers will have full instances just for testing and even DR purposes. You're right --- Active Directory is usually a pain point; sometimes our code changes (we try to never touch this), but also people want to change their AD configuration (move to LDAPS, etc.). Wrong settings, and you can lock-out your instance. If it's an uncommon / one-off testing case then a temporary trial license is fine for this.

hi @internalit_7155 Any updates on this issue? Were you able to resolve/fix this problem? We've had another customer who reported a very similar problem (activation of a key on our new server, using sha256 vs sha1, causes an error in an old ProGet version). But we still can't reproduce it, and now I wonder if it's related to operating system version, or another operating system patch that's missing. Thanks, Steve

Thanks for sending those over @RobIII At first I want to confirm, are you using the "V3" API endpoint in ProGet, for your VS2019 configuration? If not, please do that, since VS treats those APIs differently. Otherwise, there's nothing off about the index files... the most likely scenario is that there is a problematic "translation" between VS2019's API call to ProGet, and ProGet's API call to GitLab. There are more than just those index files that are used. It's most likely a bug on GitLab's end, in that they're doing something against the spec that just "happens to work" in VS2019. We struggled with a very similar bug with GitHub, but their timeline to investigate/fix it was crazy, so we just did a workaround (see PG-1932) and have it mostly working. Ultimately, the customer decided not to use GitHub in this manner, because the workflow (outside of the API) was painful and GitHub is buggy they said. So there's that. They just publish packages to ProGet directly instead. You may find this workflow better as well. Anyways... if you're already using the v3 api endpoint in ProGet, we will need to get this reproduced so we can attach a debugger and find the problem. I understand it's not feasible to provide access... maybe it won't be so bad to set-up a reproduction case with a public repository? We don't know how to use GitLab's packages features, so if you can help set that up, we can attach a debugger and get it tested. Thanks