ProGet dropPath for package imports

forbzie22_0253

Hi,

I've been looking at Progets dropPath feed property here and have a few questions:
https://docs.inedo.com/docs/proget-feed-storage

From reading about this property it says it's primarily used for bulk uploads of packages from a local or unc path.
I would like to use this feature to also upload/publish ad-hoc packages, i.e. If someone releases a new nuget package and copies this to the dropPath, ProGet would pick this change up and publish to the feed.

Are there any downsides to using dropPath in this way? And is anyone else using dropPath this way?

I guess the main question here is, is it suitable for incremental package changes as opposed to just bulk uploads?

Other questions are:
Can ProGet handle situations where multiple computers are trying to install a module from the feed while at the same time that module is being updated by the dropPath feature?

Could these be potential file locking situations where a package is copied to the drop path and ProGet is trying to access it in the dropPath?

atripp

Hi @forbzie22_0253

The use case you're describing (i.e. using drop paths as an intermediate to publish packages to ProGet) is not uncommon. It's fine, and can be simpler in many cases.

But since you asked... the downsides are that require file share access, new developers may be confused by the process (since the typical workflow is publishing directly), and that there is a lack of immediate feedback mechanism (just because file copy is success doesn't mean package is accepted). I guess those are all obvious.

As to your other questions...

Can ProGet handle situations where multiple computers are trying to install a module from the feed while at the same time that module is being updated by the dropPath feature?

Package versions are immutable and not meant to be overwritten. Instead you are supposed to publish new versions. If your workflow involves continuously overwriting the same version while continuously consuming it, you will get errors. Regardless of using drop paths or publishing.

Could these be potential file locking situations where a package is copied to the drop path and ProGet is trying to access it in the dropPath?

If the file in a drop path is locked for reading (since it's currently being written), ProGet will just try again later.

forbzie22_0253

To confirm, We would not be publishing packages and overwriting them, we would only publish new versions of packages to the dropPath so they then get picked up by Proget.

So the question here is still the same, If lots of computers are trying to pull down a PowerShell module called 'MyModule' (default to get the latest version), and someone is releasing a new version of this module by copying a nupkg to the dropPath, I wanted to check that Proget would still serve the old module fine until the new version had been released successfully.

I ask this because the internal version of NuGet server (https://learn.microsoft.com/en-us/nuget/hosting-packages/nuget-server )itself had an issue with this, when new modules were being ingested by nuget server, it sometimes caused errors for users trying to install that module from the feed.

Good to know it will retry if a lock is detected.
Also good to know other folks are using dropPaths as an intermediate to publish packages to Proget.

thanks

forbzie22_0253

Another question.
This article https://docs.inedo.com/v1/docs/proget-bulk-import-with-droppath shows the GUI option "Delete package files from path after import".
When configuring the dropPath, we would like to stop proget deleting the package after import, is this possible? I dont see an option for this in the advanced settings.
Only seems to be available for one off bulk imports via the GUI?

atripp

Hi @forbzie22_0253 , that's only possible in the one-off GUI option. It's not possible if you're using a drop path

forbzie22_0253

@atripp thanks for confirming.