Hi @steviecoaster ,
Nice suggestion; I made a small change and you can now do pgutil apikeys create feed --feed=* to create such a key.
Thanks,
Alana
Hi @steviecoaster ,
Nice suggestion; I made a small change and you can now do pgutil apikeys create feed --feed=* to create such a key.
Thanks,
Alana
Hi @steviecoaster , FYI - I just a note to the license restriction page; it looks like we don't mention the restrictions on other APIs (delete, scan, etc), but it's something we'll consider next round of docs refactoring. I know we do call it out on the main documentation pages though.
Hi @steviecoaster ,
The pgutil security features are brand new API endpoints and we haven't had a chance to document them yet. Like other new API endpoints that make ProGet easier to manage, we decided to make the new feature only available for paid editions.
Our product management philosophy is that core functionality (curate open-source packages from public repositories, centrally manage packages and containers) is available in free edition, and others are in paid edition.
Thanks,
Alana
Hi @fbiryukov_8162,
I did a quick read of the content, and based on this statement ...
"Private Marketplace is available to GitHub Enterprise customers. VS Code users must sign in with a GitHub Enterprise or Copilot Business or Enterprise account to access." sounds to me like a closed ecosystem
And these technical instructions ...
... this is a locked-down / closed ecosystem. There's no published API/specs and no still no support in VSCode for private galleries. They're just "hacking" internal settings to get VSCode to use a different service URL, which they also control.
Obviously this is not something we could/would want to reverse engineer and then support.
If the VSCode team adds support for private repository/galleries (and a public/documented API), and there's some degree of stability to that, we'll consider it. But until then, not much we can do.
Best,
Alex
Thanks for sending this over! It will take me a but to dig through this. Just a couple of quick follow up questions:
Thanks,
Rich
Hi @udi-moshe_0021,
Thanks for clarifying.
In this case, then someone may have disabled package caching on the feed or deleted the package using the "clear cache" button, a retention policy, or manually. That is the most likely scenario here.
There may have also been an error adding the package to the feed (file system error, etc), although those are very rare and would have been logged under Admin > Diagnostic Center.
Thanks,
Alana
Hi @udi-moshe_0021,
I'm afraid we don't have enough information to help troubleshoot, but I'll try to explain how ProGet works behind the scenes.
If you have package caching enabled (the default), then packages downloaded through ProGet will be automatically cached. They will still show up with the "remote" icon, but they will be stored on the ProGet server. You'll be able to tell that they're cached (instead of remote) because there will be a "delete cached package" option.
You can verify this behavior by simply downloading a package from the ProGet UI. It will cache the package. The same link/url is used by the npm client to download a package file.
So why is a package not cached then? The most likely case is that the npm client already had it internally cached, and thus it was never requested from the server. You may also have a scenario where cached packages are deleted with a retention policy.
Thanks,
Alana
Thanks for following up! Is it possible to share the contents of the JSON your API generates? You can do that by logging into Nexus and entering the following URL in your browser: https://«NEXUS_HOST_AND_PORT»/service/rest/v1/components?repository=«REPOSITORY_NAME»
Please not the Repository Name is your Docker Registry name.
The code does some stuff to strip off the registry name so only the namespace and image name are left. I'm guessing that something is being returned slightly differently. Can you also tell us what version of Nexus you are running? It might help so I can do more testing with that version.
Thanks,
Rich
Based on the stack trace, there's something wrong with the data being returned via the API from the remote connector. Specifically, one/more of the version objects being returned is missing a name or version property,
Based on the URL, the invalid data is at the {repository-root-url}/browser-sync. Here's what it's supposed to look like, based on the public repository at least:
https://registry.npmjs.org/browser-sync
Thanks,
Alana
@pmsensi sure thing!
2025.16-rc.1 should be available now.
Here's how to download it:
https://docs.inedo.com/docs/installation/windows/inedo-hub/howto-install-prerelease-product-versions