Team member here. I'd like to let you know that we've moved to the public npm registry. See Retiring the Progress NPM Registry.

@apxltd Lol, fair enough. I know MS is busy trying to get everyone on the cloud and destroying on prem. Not sure how well that's going for them. Well, let's watch and see what winget does. Maybe it will take off.

Thank you. this situation seems to be sorted in 5.3.15.

Hi @atripp Just to let you know that I just upgraded version 5.3.24 and can confirm that this issue is now resolved! Thanks so much for all your help! Thanks Simon

Hello John I upgrade to version 6.2.5b8. The sync is working. I get all the servers, and roles, BUT I have seen a weird behaviour I had 3 env defined in Otter INTEGRATION DEVELOPPEMENT PRODUCTION and only two were sync in Buildmaster. DEVELOPPEMENT PRODUCTION The servers assigned to the missing environnement in Otter were assigned to the "none" environment. In OTTER, I assigned INTEGRATION as child of DEVELOPPEMENT, ran a sync and INTEGRATION appears in Buildmaster as child of DEVELOPPEMENT I removed the link to DEVELOPPEMENT, ran a new sync. Strange isn't it ? But now, every seems to works fine until the next bug Thanks Best regards PhilippeC.

Hi @apxltd, thanks for the insights! I half expected this to be way more complicated than I had hoped for, but one can dream...

I also confirm I didn't get any more timeouts on the latest version. Very good!

Hi @aneequaye_1868, I apologize, I was speaking from the mapped folder on the Docker host. Inside the container, it is still /var/proget/packages. Does this still happen on the latest version of ProGet? We did make some changes to how the headers are returned in the latest version, especially for feeds that require authentication. Thanks, Rich

@guyk thanks for letting us know; unfortunately this would require a substantial change to the way we handle authentication on connectors; if we see more of this down the line we'll definitely consider it further :)

Hi @sebastian, Thanks for sharing your thoughts on this! Few things to point out... [1] The "Missing Package Problem" is not as bad in ProGet 2024, mostly because it will only apply when there's a license rule. In ProGet 2023, a "missing package" would happen even for vulnerabilities. [2] We're working on a new feature/module (tentatively called "Remote Metadata") that is intended to routinely cache/update meatdata from public repos like nuget.org, npmjs.org, etc. This feature enables two usecases: Routinely update "server-side metadata" like Deprecated, Unlisted on cached packages Fetch metadata for packages not in ProGet during build analysis It works somewhat independently, and basically it'll just show up on the Admin tabs as like "Remote Metadata" and you can configure providers, urls, etc. I hope to have a prototype in a couple weeks and will post some details on a new forum posts. As an FYI this is something we will limit in the Free/Basic editions and have full-featured in the ProGet Enterprise product. [3] "Package In ProGet" could be a policy rule to add after RMetadata feature, though it's probably not a big deal if ProGet can detect licenses thanks to RMetadata Best, Alex

I recently published a new version of Pagootle that supports working with Asset directories, includes some other fixes, and improves the documentation.

@saml_4392 in theory it's fixed, but we didn't test it Could you open a new thread about a creating a Helm chart for ProGet itself? That'd be a great place to start that discussion, and get community direction and feedback from users - and provide nice opportunities to partner with organizations like bitnami, who could help

PyPI support has now been added and published as a pre-release version of 5.2.0. Visit the ProGet Versions page to download, or get it from the Inedo Hub download.

I've now found a cleaner way of adding this entry to the host file... If using docker run, add the argument: --add-host=<host_server_name>=127.0.0.1 if using a docker compose file, add an entry: extra_hosts: - "<host_server_name>: 127.0.0.1"

Discussion should be moved to a new post or followed here: http://inedo.com/support/questions/6554

@michal-roszak_0767 said in Pull Maven artifacts - invalid version: Next victim: https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/ jeeze, what a mess! Well, there goes any hope of using v[0-9]+ -- they just straight up use random strings as version numbers. https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/. https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/Neumann-SR9/ Open to ideas, but based on the URLs alone... I don't see a good way to identify one of these as an artifact and the other as a version of an artifact.

Since there is no further update and no solution for my problem using nuget cli or dotnet cli I am closing this thread.

Hi @scroak_6473, Glad to hear it! Thanks, Rich