Hi @m-lee_3921,
When specifying a package source, the package must be in the same feed; you could specify it using a URL however.
{
"virtualPath": "common/logo/logo.png",
"source": {
"url": "http://proget/endpoints/customer-assets/content/ast-logo.png"
}
Good point on the documentation; download-vpack is for the .vpack file only (i.e. manifest). I'll update it
-- Dean
@uel_2013 (I deleted my previous reply since I learned a few more details from a team member who talked with you already)
Given your team size, you'd definitely be better off upgrading (rethinking) your CI/CD processes when switching over to BuildMaster. As some users have told us, the Octopus Deploy way is like "trying to apply the SVN mindset in a Git world".
The main benefit to a small team is that it's a simplification/consolidation of build- and deployment tools, while also giving you a powerful platform and process. We're working on "codifying" this in an upcoming guide called Lean Platforms: Engineering & Orchestration.
You could likely get BuildMaster to work in a similar way (i.e. a "deployment script runner"), but you'll be "fighting against the current" and you would be missing out nearly all of the benefits. For example, we have different ways of handling multi-tenancy (e.g. depending on if you do quasi-custom software) and the Git and Issue-tracking integration will make a huge difference in your internal processes.
I'd suggest taking a quick tutorial of the software (you can freely download it), and see how far you can get with setting a basic application from scratch. That should help you see the differences and how the concepts maps. There are a lot of similar ideas, but like Git and SVN, there are differences that don't translate very well.
-- Dean
Hi @thomas_3037 and @felfert ,
We heard from another users that creating a new signing key in the feed worked, so please try that.
We didn't experience that in our testing, but I suppose it's not all that unexpected given the scope of the changes. We will update the documentation / blog post and also try to put some guidance in the software via PG-3157 to help other users who encounter an error like this.
-- Dean
Hi @rick-kramer_9238 ,
It looks like you're using ProGet 2023? That functionality was relatively new in that version and there is very possibly some kind of bug linking the two together.
We've since made some big improvements to SCA/compliance, so I would recommend upgrading. Many of the changes were in ProGet 2024:
https://docs.inedo.com/docs/proget-upgrade-2024#new-features-in-proget-2024
-- Dean
Hi @felfert ,
There were major changes to Debian feeds in ProGet 2025.14:
https://blog.inedo.com/inedo/proget-2025-14-major-updates-to-debian-feeds
They were thoroughly tested and we did not encounter issues when upgrading and switching back/forth between versions. As you might imagine, we don't have enough information to help you troubleshoot this - so we'd appreciate if you could investigate further.
It is most certainly a client-related configuration issue and you may need to reconfigure the keys, clear a cache, or something to that effect. Signing keys are typically not changed for already-configured repositories, so this isn't common client behavior.
Please let us know what you find, so we can document appropriately.
-- Dean
Hi @d-kimmich_0782 ,
This behavior is by design; the "publish date" in ProGet 2025 and earlier is whenever a package is added to a feed. This means that, even if a package was published to NuGet.org 3 years ago, the "publish date" will be whenever it was first cached.
However, in ProGet 2025.14 and later, you can change this behavior under "Admin > Advanced Settings > Use Connector Publish Date". This will be the default behavior in ProGet 2026.
This is being done for a similar set of rules you should investigate, which we call Recently Published & Aged Rules :
https://docs.inedo.com/docs/proget/sca/policies#recently-published-aged-rules-proget-2026-preview
-- Dean
Hi @gisleso,
But I'm starting this topic to ask if its expected behavior that formatting of uncached remote packages is a litte off? See screenshots.
Good catch. In this case, the ProGet implementation of the warehouse API (which connectors use) was using the "description" field instead of the "summary" field. Easy fix, it'll be handled via PG-3151 in the next maintenance release
And if anyone have experience with promoting packages including their dependencies I am open to suggestions. (Right now I'm thinking a script that first pull the packages, and the loop to pull/promote the depedencies)
This is frequently requested, but it's simply impossible to do. The only way to solve this is to restore from your unapproved feed, then promote the dependencies into your approved feed.
The reason is that this would require ProGet (or your script) to perform a "dependency resolution" which is impossible to do without environmental context (i.e. other packages installed, operating system, and client configuration).
This is because dependencies are not only specified as ranges (e.g. hypothesis requires sortedcontainers<3.0.0,>=2.1.0) but they often include usage constraints (e.g. hypothesis specifies redis>=3.0.0; when extra=="redis" is specified) and environmental constraints (e.g. hypothesis specifies tzdata>=2025.2 but only when (sys_platform == "win32" or sys_platform == "emscripten") and extra == "zoneinfo").
Only a package manager tool (e.g. pip) can perform dependency resolution, and even then it's not deterministic. This is why lock files are so important too.
-- Dean
Hi @mayorovp_3701,
Based on the message, it appears to be a bug/problem with the GitLab API. It's indicating that the required PackageBaseAddress endpoint is not present in the service index.
Can you share the "service index" (i.e. the index.json) file? It should be present at the root of the API and look something like this: https://api.nuget.org/v3/index.json
-- Dean
Hi @koksime-yap_5909 ,
Data deduplication is an operating-level system function. On Windows, there's the Data Deduplication Feature. There are more options for Linux, but ZFS Deduplication is pretty popular.
-- Dean
Hi @davi-morris_9177 ,
For multi-file packages like PyPI, the entire package (i.e. all the files) is promoted. This is the same in the UI as well.
-- Dean
Hi @Nils-Nilsson,
Thanks for the report; this was a trivial fix and I just committed the change to PG-3138 , which will be in the next maintenance release (Oct 24).
As an FYI, if you uncheck "Restrict viewing download statistics to Feed Administrators" on the Feed Permissions page, then error shouldn't occur.
-- Dean
Hi @koksime-yap_5909 ,
Docker registry import from Sona, JFrog, and other ProGEt instances is coming soon via PG-3128 - we anticipate that in the next maintenance release.
As for Assets, I'm afraid we don't have any support for that planned in the near future - it's relatively easy to write a script that "extracts" them - if you could extract it to a ProGet drop path, then they'll be imported that way.
https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-bulk-import-with-droppath
-- Dean
Hi @jfullmer_7346 ,
I'm afraid I can't reproduce this data that lead to this error; I did manually hack the database to get it close to what your results showed (i.e. WinSCP and winscp) -- and I got an error the first re-index, but then it got fixed a second time.
At this point, it would require having your database and attaching a debugger to see what's going on. That's a bit more effort than we're able to spend today on a community / non-paid user today, especially given the trickyness of this bug.
HOWEVER -- since you're familiar with PostgreSQL, it might just be quicker to DELETE the duplicate / unused PackageVersionIds and PackageNameIds. That's what we had done in previous versions (2024 and earlier) when there was a problem. Once you have a single record, you can update the casing pretty easily.
Or if you don't care about any packages, just start a new instance of PRoGet and add the packages in. This is all happening b/c "bad data" got snuck in the database in the first place.
-- Dean
Hi @fabrice-mejean ,
Oh I see; that's basically just an alternative URL to query, instead of (or in addition to) official public repositories.
For example, the OSS Metadata Provider for npm is https://registry.npmjs.org. A Custom Provider is one with an alternative URL. Maybe a vendor site, or a differente repository that uses the same APIs?
As the docs mentioned, we have no idea why anyone would want to do that. But it's technically possible.
Thanks,
Steve
Hi @mmaharjan_0067 ,
It sounds like you're on the right track with researching this; your reverse proxy is definitely "breaking things" somehow.
Based on what you wrote, it sounds like your reverse proxy is terminating the request because there's no output from the server after a while. The "no output" is expected, since assembling the upload takes quite some time, and that's likely where the "operation cancelled" would be coming from.
I would look there and see if you can adjust timeouts. As for pgutil, here's the code used to perform the multi-part upload:
https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/AssetDirectories/AssetDirectoryClient.cs#L197
-- Dean
Hi @ashleycanham ,
This is a fairly complicated issue behind the scene, and is related to how these packages have multiple casings across different versions.
This is something that should be addressed with PG-3100. After upgrading, you'll want to re-index the feed. If any packages still have incorrect casing, you can re-upload them to ProGet to correct the names.
-- Dean
Hi @power_pille ,
That's strange; I'm wondering if there's some kind of collation problem on your database.
Can you run this?
SELECT CONVERT (varchar, SERVERPROPERTY('collation')) AS 'Server', collation_name as 'Database' FROM sys.databases WHERE name = 'ProGet';
What are the collation you're seeing?
ProGet must be SQL_Latin1_General_CP1_CI_AS
-- Dean
Hi @dev_7037 ,
This is not possible and we have no plans to add support for this.
Some users have reportedly used reverse proxies and page/URL-rewriting, but it's a headache and usually causes problems. Best to use a different host name and change URLs accessed by clients.
-- Dean
Hi @Anthony ,
The API Access Logs are intended for troubleshooting purposes, not auditing/access monitoring. So I'm afraid there's no way to increase it.
-- Dean
Hi @power_pille ,
I haven't seen that error before, but I suspect it could occur during a race condition while simultaneously trying to access newly-accessed packages. During an intense package restore, the window for the race condition would widen.
It should go away however. If you can look at the error messages logged in ProGet, it'll help give an idea:
Violation of UNIQUE KEY constraint 'UQ__PackageNameIds'. Cannot insert duplicate key in object 'dbo.PackageNameIds'. The duplicate key value is (nuget, <NULL>, NuGet.CommandLine).
In this case, the package is NuGet.CommandLine -- so hopefully you wouldn't see that again. Let us know if that's not the case, and if you repeadly see the same package.
-- Dean
Hi @yaakov-smith_7984 ,
We do not have this API, but it's on our roadmap for Q4; it's going to be a set of command like pgutil users or something to that effect.
-- Dean
@tames_0545 thanks for letting us know, we'll get this fixed right away via PG-3065 in the next maintenance release
Hi @mickey-durden_1899 ,
I've not heard of OCI's Object Storage before, but that error message is coming from the AWS SDK. I searched it, and it's basically saying that OCI doesn't support payload signing, which is used by chunked uploads?
I'll be honest, I have no idea what that means... but it looks like Cloudflare's version of S3 also doesn't support it. But we can apparently just make a small change to get it working: https://github.com/cloudflare/cloudflare-docs/issues/4683
I'm thinking we could try adding a checkbox to disable Payload Signing:
https://github.com/Inedo/inedox-aws/blob/master/AWS/InedoExtension/FileSystems/S3FileSystem.cs
Assuming we did that, could you install the pre-release extension and try it out? If it works, we'll publish it.
Thanks,
Steve
Although ProGet can handle invalid version numbers for Maven packages, this one is a extra invalid version number (it starts with a "v") and unfortunately we can't support them at this time.
ProGet requires that packages follow the ~20 year Maven standard that "packages start with a letter and versions start with a number". Sadly this team didn't like those standards and opted to do their own thing.
The issue comes with identifying whether com/google/apis/google-api-services-healthcare/v1-rev20240731-2.0.0 is an artifact or a version. Because ProGet is not a basic file server, things like package names and versions matter.
Anyway this will require a significant and risky change to the API so we won't consider it at least for another major release.
-- Dean
@tames_0545 thanks for letting us know! We'll see if we can improve troubleshooting on this in the future as well!
Hi @darren-sloper_5044 ,
ProGet does not currently produce HTTP Access Logs, though we are considering that for a future release. It's really easy to add it via an IIS reverse proxy (WIndows) or with some NGNIX settings if you're on Linux
Dean.
Hi @Jonathan-Engstrom ,
There's no way to "merge" accounts that I can see, so I just changed the ownership of the handful of posts by @JonathanEngstrom to @JonathanEngstrom and updated emails. Hopefully that works
-- Dean
Hi @kc_2466 ,
We'll get this fixed via PG-3050 as well; the button should be shown to non-admins
-- Dean
Hi @kc_2466 ,
Those should not be displayed to non-feed admins; we'll clear that up with PG-3050 in the next maintenance release. In the meantime, I suppose you could just click the "X" for them ;)
-- Dean
Hi @mmaharjan_0067 ,
We'll investigate and see about adding this via PG-3035; it's probably returning some unexpected status. Will update if we run into trouble!
-- Dean
@mmaharjan_0067 we'll try to do this via PG-3034 as well
Hi @v-makkenze_6348 ,
We'll get this fixed via PG-3041 in the upcoming maintenance release; you can try out the prerelease container if you'd like (proget:25.0.4-ci.1), which is building now.
-- Dean
Short answer yes, and you'd probably see a bit better than 15 -> 5 TB reductions with those artifacts. We usually see 90-95% storage space reduction. Pair it with ProGet's retention rules and I wouldn't be surprised to see that drop to 500GB.
Long answer, file deduplication is something you want handled by the operating system (e.g. Windows Data Deduplication, RHEL VDO, etc), not the application. It's way too complex -- you have to routinely index a fileset, centralize chunks in a compressed store, and then rebuild those files with reparse points.
Maybe this wasn't the case a couple decades ago. But these days, rolling your own file deduplication would be like implementing your own hacky encryption or compression. Pointless and a bad idea.
That being said, you may be using a tool by our friends at JFrog. They advertise a feature called "data deduplication", which IMHO is something between deceptive and a clever marketing flex.
Because they store files by their hash instead of file names, the files are automatically "deduplicated"... so long as it's the exact same contents. Which, in most case, it will not be.
Here’s an article that digs into how things are stored in Artifactory, and also should give you an idea of their “file-based” approach: https://blog.inedo.com/proget-migration/how-files-and-packages-work-in-proget-for-artifactory-users/
As for the package count, 5M is obviously a lot of packages. Obviously it's not going to be as fast as 5 packages - but probably not that much noticeably slower. There's lots of database indexes, etc.
Hope that helps.
-- Dean
@michal-roszak_0767 just a heads up we're a bit slammed with ProGet 2025 release but will respond soon!
@lukas-christel_6718 just a heads up we're a bit slammed with ProGet 2025 release but will respond soon!
@layfield_8963 no plans, as you're the first to ask :)
I don't know much about ARM/MacOS builds.... do you think it's just as easy as adding a new publish target?
See our build script here:
https://buildmaster.inedo.com/applications/132/scripts/all?global=False
Hi @parthu-reddy ,
Nothing to worry about - there are a few ways this can happen, and unless it's happening a lot and/or causing problems with your end-users / pipelines / etc., you can ignore the message.
-- Dean
Hi @alex_6102 ,
It sounds like you're trying to do a kind of "manual" or "custom" installation on Linux? That's the impression I got when you mentioned, "using the file system provided..."
We don't support this kind of installation,; you should really just run the Docker image like this:
docker run -d --name=proget --restart=unless-stopped \
-v proget-packages:/var/proget/packages -p 80:80 --net=inedo \
-e PROGET_SQL_CONNECTION_STRING='Data Source=inedo-sql; Initial Catalog=ProGet; User ID=sa; Password=«YourStrong!Passw0rd»' \
proget.inedo.com/productimages/inedo/proget:latest
As for the error... it seems that ProGet is failing to read the configuration file, which isn't used on a Linux installation. Instead, environment variables are used, since that's the Docker way.
-- Dean
Hi @darren-sloper_5044 ,
That's great to see you're giving it a shot! We'll fix this via PG-2992 in the next maintenance release, but in the meantime... it looks like the bug is in the download statistics procedure, so if you disable that feature on the feed it should work.
Let us know what else you find,
-- Dean
@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.
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 @michal-roszak_0767 ,
ProGet does not support wildcards searching for artifacts.
Licenses are declared in the manifest (i.e. .pom file):
https://maven.apache.org/pom.html#Licenses
You cannot really override this. If an artifact does not have a license, you will be given a chance to pick a license for it. If you ever need to change that, you'd have to go to the SCA > Licenses > License Types, and remove the package-specific assignment from there.
-- Dean
Typically, Deployment Targeting is done in the Pipeline:
https://docs.inedo.com/docs/buildmaster/deployment-continuous-delivery/buildmaster-pipelines#deployment-targets
This way, you don't need to put for server or anything in your script.
So, my guess is that your Pipeline is actually targeting the ProductionServer (but not running anything on it, except intializing the agent), but your script is targeting the BuildMasterServer.
-- Dean
@michal-roszak_0767 ProGet is not a file server. Metadata files like maven-metadata.xml are generated upon demand, based on artifacts stored in the feed
After looking into this further, I'm afraid we simply can't support this artifact/package at this time. I don't really see a good path for supporting this without adding significant complexity and risk of breaking proper artifacts / versions.
The problem is that this version breaks the basic rules that Maven repositories need to follow:
These rules resolve the ambiguity of determining what /com/google/javascript/closure-compiler/v20250407 means. For example, is it:
v20250407 of com.google.javascript.closure-compiler artifact?com.google.javascript.closure-compiler.v20250407 artifact?I'm not even sure how this was uploaded to Maven central. I have no idea why the developers ignored the warnings that Maven spat out for legal version numbers. This has been a specification for like 20 years. Heck, here's a discussion from like 2008 on how the "must start with a digit" rules needed clarification: https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
If you encounter other artifacts like this, maybe we can consider some kind of very limited exception, but until we figure something else out this artifact version is simply not supported in ProGet.
I can't imagine there are many other artifacts like this, but let us know if there are.
-- Dean
Oh that's a whole lot of connectors and this is most definitely going to cause some performance issues.
Remember that ProGet needs to forward every request you make to all 10 of those servers, and some of these repositories will not respond very quickly. Like JCenter was deprecated/retired a few years ago, and I can't imagine is performant at all. Especially for things like metadata requests.
Maven is not a very patient client and will time out while waiting for ProGet.
There is really no way around this. You'll need to use less connectors.
-- Dean
Hi @michal-roszak_0767 ,
That error is unrelated to invalid versions being allowed/disallowed in ProGet. Maven is just saying that it can't find a snapshot (i.e. prerelease) version of a dependency.
'io.github.java-diff-utils:java-diff-utils' is a public library, published to Maven Central:
https://repo1.maven.org/maven2/io/github/java-diff-utils/java-diff-utils/
Snapshot versions are not published to Maven Central. I don't know where it's published.
In any case you should not be using snapshots of public libraries unless you have a very specific need to; they're only intended for development of related public libraries and are in a special repository. Check w/ the devs behind that build with their intents... it might be a mistake?
-- Dean
@michal-roszak_0767 those are also invalid versions and you should never upload them to a feed (repository) directly; see https://docs.inedo.com/docs/proget/feeds/maven#snapshot-versions
The code has already been fixed and the maintenance release is scheduled for next week. We could get you a prerelease, but I don't think your developers are manually uploading artifacts using the Web UI?
If you want to upload artifacts with bad versions now you can just use the maven client (e.g. maven-deploy) or just do a basic PUT of the file to the desired group/artifact-id.
Hi @michal-roszak_0767 ,
It looks like the manual upload page does not consider that setting; we'll fix it via PG-2977 in the next maintenance release.
-- Dean
Hi @michal-roszak_0767 , @steviecoaster ,
Maven versioning is a total mess. v*** is indeed an invalid version, per the which means that (among other things) it must be lexicographically sorted for determining latest version.
It looks like they knew that enough to use a string... but not enough to use a valid version number. Oh well. /rant
If you go to Manage Feed Settings, you can enable invalid versions in the feed. The message should make this more clear, so I will clarify that via PG-2977 in the next maintenance release.
-- Dean