Posts made by dean-houston

Hi @manuel-riezebosch_8638 ,

It looks like the HTTP Endpoint documentation for the pgutil packages upload command was not accurate. A purl is not used here. I've updated the docs as follows...

To upload a package, simply PUT to the URL with a feed name, an appropriate API Key and a package in either ZIP, JAR or TAR format depending on the value of the Content-Type header.

PUT /api/packages/«feed-name»/upload[/«package-file-name»]

The «package-file-name» part of the URL is only required for the PyPI and RPM feed types, while Debian feeds will require a distribution argument and an optional component. See the corresponding upload package method on ProGetClient.cs for the most accurate and up-to-date pgutil and HTTP endpoint argument mapping.

Hope that helps!

-- Dean

Hi @Nils-Nilsson ,

It's not really possible to "send a notification" without all the context (like Package Version, Name, etc.), but there is a relatively easy way to test that notifications are being sent (i.e. when you add a package).

If you configure a Email Notifier, you can check off the "Add notification in ProGet". You can enter a "fake email" or not even configure SMTP settings.

When you do that, it will still add a notification to ProGet (under Admin > Notifications) with the same body as the email.

-- Dean

Hi @certificatemanager_4002,

I'm not sure I totally understand the question :)

The ConnectionString property is marked as encrypted, which means that ProGet's Encryption Key will be used to store it to the database as encrypted, and obviously decrypt it.

But this should happen automatic, when using the API or UI to save the settings.

-- Dean

Hi @ybaskar-temp_3339,

Going off of memory here (this was like 10 years ago), but I believe that BuildMaster v5 would hide legacy options unless there was already legacy data. Since there's no legacy plans there's no button.

However, it still should be possible if you can find the url of the page to navigate to. I would check other apps for that option, inspect the url, and just replace it with your applications Id.

Let us know if that works!

-- Dean

@pg_user_8607 very cool, great practical use of the new ".cs scripts" type applications! I think this could make a nice blog post... I'll point this to our technical writers!

Hi @devops_8569 ,

I'm afraid this is a known limitation issue with Maven versions in ProGet for now.

Long story short, ProGet followed these versioning specifications:
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

However, some packages did not follow those specifications but instead relied on undocumented quirks (bugs?) in the Maven version parsing. These are now somewhat documented: https://maven.apache.org/pom.html#version-order-specification

It'd be nice to fix, but it would require a risky, non-trivial rewrite of our Maven version parsing to solve this. So far as we can tell, the only consequence is that a small number of vulnerabilities yield false positives. So, it's not a priority.

In ProGet 2026, we are substantially changing vulnerability management so it's likely these false positives won't be an issue anymore. For example, PGV-2314320 would be rated as a PVRS Category 2 for most environments.

We'll evaluate / explore this after getting feedback from users in ProGet 2026, and whether they think it's worth us investing the time/risk to address this limitation.

-- Dean

Hi @parthu-reddy ,

Thanks for the additional information. Thinking about it further, I suspect this was a temporary network outage. It could have been DNS related, or who knows what.

As for your configuration...

5000 is definitely too high; set this towards 100-500 max. If you're working on a load-balanced cluster, this should be done at the load balancer instead.

I was incorrect about api.nuget.org, that is also used by the V3 API. I thought it was only V2. So please disregard.

It's unlikely metadata caching will help, but you could try it. That's a relatively short-lived cache meant for traffic bursts, and it's not really going to help with a network outage.

-- Dean

Hi @parthu-reddy,

Thanks for the detailed investigation notes. From what you've described, the behavior doesn't appear to be related to SQL Server locking. It's most certainly related to blocking/waiting on the 200+ outgoing connections to receive a response from api.nuget.org.

If api.nuget.org is running slow, then ProGet will run slow. There's really no way around this when you use connectors, as ProGet is effectively forwarding client requests.

Most likely, someone or some build server is making legacy/V2 NuGet API requests (they look like ODATA/SQL queries on the url), and those are being forwarded. The V3 requests are just JSON files.

-- Dean

Hi @0xFFFFFFFF,

Thanks for the detailed write-up and explanation.

It looks trivial to add size and upload-time. Adding versions is probably simple, assuming it's just an array of distinct version numbers (we already have all the "packages" in context).

It's probably fine, but just to be safe we will do this in ProGet 2026, given some of the subtle behavioral changes you mentioned ("tools like uv to make use of heuristics to speed up downloads"). For someone with an overloaded server, that might "put it over the edge".

ProGet 2026 may be ready by the end of the month, so it's not so far away.

-- Dean

Hi @Nils-Nilsson ,

Thanks for the bug report; it seems to issue is on the "view" page, and it's mistakenly editing the wrong data.

PG-3258 will fix this in the next maintenance release (April 17), but a prerelease is now available (inedo/proget:25.0.26-ci.6) if you'd like to try it.

-- Dean

@rcpa0 thanks for letting us know; we'll try to fix this next time we make some changes to pgutil it should only print "Version is not a valid semantic version." or something

Hi @geraldizo_0690 , unfortunately we didn't get a chance to review this for the last maintenance release, but it'll be in the next one (April 17) via PG-3257. It's also available via prerelease if you'd like (inedo/proget:25.0.26-ci.5)

-- Dean

Hi @davi-morris_9177 ,

I'm afraid this behavior is expected because kotlin-stdlib-2.3.20.jar is not in the downloaded index file. There's is no file-listing API, which means there's no way to know what should be there otherwise.

The Maven client downloads "blindly downloads" some files, and "silently accepts" a 404 for other files. When it's downloaded (cached), then ProGet knows about it. So, you really need to download the artifacts first if you want to make a curated feed I'm afraid.

-- Dean

Hi @certificatemanager_4002 ,

Check out our Licenses for Non-production / Testing Environments for the full details.

But if its a short-term migration testing scenario, then using an existing or trial key is fine. For a long-term environment, a separate license is required.

-- Dean

Hi @adoran_4131 ,

Keep in mind that ProGet and Artifactory work differently; Artifactory is basically a "file server" and is just does "blind proxying" of HTTP requests. That's why it doesn't matter what URLs you put in. ProGet, on the other hand, is a package server, and will index the remote repository first. That's where things are failing right now.

It's failing because the index file is not being found based on the input. This is what a Debian repository is supposed to look like:

dists/
    {distribution-name}/
        Release
        Release.gpg
        main/
            binary-amd64/
                Packages
                …
pool/
    main/ …

So, the distribution-name is incorrect. I thought it might be binary based on the instructions, but these URLs are both a 404:

https://pkg.jenkins.io/debian-stable/dists/binary/Release
https://pkg.jenkins.io/debian-stable/dists/binary/InRelease

So, it must be something else. It's whatever apt is sending by default, I guess?

Anyway, if you can find what distribution it should be, then it will work. Perhaps consider just doing something like this:

sudo apt update -o Debug::Acquire::http=true

That will show you the HTTP requests being made, and you can see exactly the URL for the Release file, which you can then use to reverse-engineer the distribution name.

Let us know what you find!

Hope that helps,
Steve

Hi @parthu-reddy ,

Sorry on the slow reply, check out the link I sent you via t icket! Just let us know when you upload the files and we'll talke a look then!

Thanks.

-- Dean

Hi @scusson_9923 ,

Can you share the OtterScript where you tried the try/catch ? Perhasp that's just something we can more easily fix.

-- Dean

Hi @tyler_5201,

The UI package search is pretty basic, so it's not going to look through those metadata properties. They are something you could obviously search/find through the API.

Depending on what you're trying to do, we do have a Whitelabel feature that makes the UI a lot easier to consume for end-users:

• https://docs.inedo.com/docs/proget/administration/whitelabel
• https://inedo.com/proget/case-studies/salient

In particular, the "Tile View" on Universal Packages may help. But it's not very popular and is something we work closely with our users on, so let us know if that's of interest.

-- Dean

Hi @tyan-yin_2201,

It looks like it's only supported on FeedCommand -- I'm not entirely sure why. It appears to be settable when calling the HTTP API however.

We ought to be able to add it relatively easy, but can you share the use case? It's also good to know why someone would want to explicitly set an api key from command line (most tools don't seem to support this).

-- Dean

Hi @udi-moshe_0021 ,

It looks like there's something wrong with your configuration file:
https://docs.inedo.com/docs/installation/configuration-files

It looks like there's a bad/missing PostgreSQL string in there. I don't know how that happened.

-- Dean

Hi @udi-moshe_0021 ,

If you can try it now, the installer should be published.

-- Dean

Hi @udi-moshe_0021 ,

I'm sorry I'm not really able to understand what the specific issue is based on your response. If you can share specific error messages or specific things you're seeing, we might be able to help.

Otherwise there are no known issues installing ProGet on Windows, and if you're having an issue it's almost always a security/antivirus tool that's interfering with modifying system configuration.

-- Dean

Hi @udi-moshe_0021,

If there was no error during installation, it's hard to say; perhaps something is going on with the Windows Service registry, or you need to refresh, or who knows.

I would try rebooting and then installing again.

There is no service for Postgres, just INEDOPROGETSVC

-- Dean

Hi @mayorovp_3701,

This is a bug you should definitely report to GitLab -- it's clearly required by the API and all other registries support it. Without that API defined, we have to "make guesses" based on undocumented conventions (i.e. /v3-flatcontainer/{id}), which causes headaches down the line. That's why there's an API contract :)

I don't know how/why it works with dotnet sdk -- perhaps it's using a different endpoint, or maybe it's not actually working and just going to NuGet.org. Whatever the case, it doesn't make sense for us to build workarounds for easily-fixable bugs on GitLab when other vendors seem to follow the API contract.

-- Dean

Hi @jw ,

Nice catch, we'll add pgutil builds delete and pgutil builds projects delete via PG-3189

You may be able to use pgutil builds create to archive a build (`--inactive), but I'm not sure. Either way, there's no way to flip it back, so we will update it.

The create command can also update, but it's not clear, so we will edit the help text to clarify.

-- Dean

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

Hi @misael-esperanzate_5668 ,

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