inedo-engineer

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

Hi @parthu-reddy ,

These are stored in the database and if you click "status" you can see the cached queries.

Does this metadata caching feature reduce the queries to fetch versions that you mentioned?

Yes, instead of going to NuGet.org, the database will be queried.

HOWEVER, this may actually reduce performance; NuGet.org is a static file system running on Azure Blob storage, and it might be quicker to download the query from Azure than to query your SQL Database.

You'd really need to expirement and see which is faster / more load.

Thanks,
Alana

@michal-roszak_0767 it wouldn't hurt to start a new topic about it, but it's design decision so you'd have to make a good use case for it :)

I can't find the discussion (maybe it was internal), but the idea is that "generic website connectors" for Asset Directories are a poor solution for "offline" environments. A "generic proxy" like ngnix will always be better in every way.

Hi @michal-roszak_0767 ,

Ah, that's what I thought you were asking in the first place :)

No, that's not a supported use case, I understand it's a design decision

Thanks,
Alana

Hi @michal-roszak_0767 ,

Thanks for clarifying; I thought you were looking to "proxy" a website like that...

ProGet has Asset Directories, which basically acts like a web-based file system.

Thanks,
Alana

Hi @michal-roszak_0767,

By RAW repository, I think you mean like a website / web-based file system?

In any case, that's not something ProGet is designed to do -- I guess that'd be more like a "generic HTTP proxy server" type of tool?

Cheers,
Alana

Hi @ds_6782 ,

If you haven't already ,I would make sure to check out the docs here:
https://docs.inedo.com/docs/proget/feeds/nuget/symbol-and-source-server

The NuGet client will automatically push both packages when you issue the dotnet nuget push command. You do not need to push then separately.

It looks like, for whatever reason ,your NuGet client isn't doing that? We don't see this problem very often - it "just works" - and I'm not really an expert at troubleshooting NuGet client configuration.

But that's where I would start. It looks like the issue is on the client end, and somehow your clientis misconfigured to not push the source packages.

Thanks,
Steve

Hi @ds_6782 ,

nuget search uses the v2 API, so this behavior is to be expected.

Thanks,
Steve

Hi @parthu-reddy ,

The default Timeout is 10 seconds, but you can configure it on each connector.

There is no "connection pool" for NuGet -- these are just normal HTTP connections like your browser or any other web api.

Thanks,
Steve

Hi @e-rotteveel_1850 ,

Just as an FYI, this was much more complex that it seemed, and we ended up creating a whole new feature to address this called Feed Integrity Checks.

This will shipped in friday's maintenance release, and in theory should spot and allow you to resolve the issues:https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-feed-storage#feed-integrity-checks

Alex