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

Hi @kenneth-garza_2882 , Based on your use cases, an extension wouldn't be a very good fit... and Webhooks are the way to go. For ProGet (unlike BuildMaster/Otter), extensions are really specialized, and it's pretty rare for folks to make their own, and we're keen on helping anyways. For example, depending on what your vulnerability scanning software is, we'd love to help and even adopt the integratino, so other users can use it. The main three things we see are: Cloud Storage; https://github.com/Inedo/inedox-aws https://github.com/Inedo/inedox-whitesource Vulnerability Scanning / Package Blocking https://github.com/Inedo/inedox-sonatype https://github.com/Inedo/inedox-azure User Directory https://github.com/Inedo/inedox-inedocore And the best way to do those, are mostly to copy the examples/code we already have. Let us know more details, and we can do ourbest to help! Thanks, Alana

Hi, I have now been able to get into the database and add my own username. This has allowed me to upgrade to 5.2 and we are planning to upgrade to 5.3 once the devs confirm the breaking changes won't have an impact. Thanks for your assistance.

Hi @tomg_5321 Glad you can get some results using the non-filtered search. If there is more demand, we may implement it... but you're the first person mention it. However, based on your requirements, I don't think you should use search.. my actual underlying requirement is to test if a certain version (which may not be the most recent) of a certain package (by exact id) exists on the server, in an efficient way, for use over relatively low-performance network links (ie, not over local LAN) In this case, I recommend you just do a HEAD request on this URL: /nuget/<feed-name>/v3/catalog/<package-name>/<version>.json For example in PowerShell, Invoke-WebRequest -Method Head https://proget.inedo.com/nuget/NuGetLibraries/v3/catalog/inedo.buildmaster.sdk/2.0.0.json A 200 means package exist, a 404 means it doesn't exist. Cheers, Alana

Hi Greg! thank you very much for your example. With that we were able to make it work! Can't wait for the upcoming update and what cool stuff it brings to the table! Kind Regards Dennis

@maxim_mazurok this has been implemented for a couple years now -- however it is still considered an "Experimental feature" because the npm audit API is undocumented and npm, Inc. does not support third-party implementations. Instead, ProGet will attempt to forward requests to the audit endpoint to npmjs.org or a connector. This may stop working if npmjs.org changes the API or blocks ProGet's requests. They've only changed APIs once, and we've promptly fixed it. In any case, you can configure the proxy URL in ProGet 5.3 by navigating to the Manage Feed page on your npm feed.

Hi @izzy95453_1154, I think the next step is to verify that your connector is configured correctly. Can you search in the ProGet UI for mssql/server? That should return the remote image for SQL Server. If you then click on the the Remote Tags tab and then click on 2019-latest, you should see the command syntax for pulling that image. Can you please verify that matches what you are using? ~ Dan

Hi @paul-reeves_6112, No problem! Always happy to help. Thanks, Rich

Hi @paul-reeves_6112, That's ok. It went through our internal testing and everything looked good so we pushed it to production with the last release. Thanks for verifying this for us! Thanks, Rich

Hi @paul-reeves_6112, Thanks! Always happy to help. Please let us know if you find anything else! Thanks, Rich

Hi @harald-somnes-hanssen_2204, Thanks for sending this over to us. It is very helpful! We will definitely be discussing this further as a team! Thanks, Rich

Hi @rbenfield_1885, It looks like you are using the integrated webserver. It looks like this error is happening when it is attempting to register the port on Windows. Please make sure that the user is an administrative user and that the port that you are using for ProGet is not already in use. Can you share the error that you are getting when you are trying to upgrade to ProGet 5.3? Thanks, Rich