Hi @andreas.unverdorben_1551 ,

Just as an FYI, I submitted two pull requests for this:

• https://github.com/github/advisory-database/pull/8689
• https://github.com/github/advisory-database/pull/8690

Thanks,
Alana

@Stephen-Schaff said in API to apply an Alternate Tag to Docker Container Image:

Here is the PowerShell function that does both the promotion and the tagging (incase anyone ever needs something like this). Kind of a "do it yourself" repackaging. (Might be nice to have the Repackaging API support Docker container images someday).

Thanks for sharing this, I've added it to our Semantic Versioning for Containers docs page, I hope that's okay :)

And yes I agree, it woudl be nice to make this an easier API call

Hello; you'll need to change the BaseUrl in advanced settings so that ProGet can construct an absolute URL when needed (certain NuGet fields, etc). I've updated the docs to reflect this.

Hi @carl-westman_8110 ,

The error message means that the database wasn't updated as per normal during the start-up process. It's hard to guess why, as we have special handling for that.

It's likely that restarting the service would have fixed it, but downgrading and then upgrading would also force an upgrade as well. Unfortunately it's hard to say at this point.

Upgrading to 2025.10 should be fine.

Thanks,
Alana

You can reset the Admin user account password by stopping the ProGet Windows service, then running ProGet.Service.exe and selecting the "ResetAdminPassword" option. Make sure to restart the Windows service when finished.

Hello; I've updated the documentation to clarify this, but it's available starting in ProGet 5.2.9. So, you'll need to upgrade to enable it :)

Hi @m-lee_3921 ,

Thanks for the heads-up; we'll get this fixed via PG-3059 in the next maintenance release (scheduled for later today).

And you're right -- its basically the same issue. SQL Server silently truncates string values whereas PostgreSQL does not, hence these errors.

We decided to not auto-truncate, since it's better to know about these cases than not. In this case, it's a IPv6 address that was longer than the 20-character limit. We plan to refactor API key logging at some point, so we'll just continue to truncate v6 IPs.

Thanks,
Alana

I'm not very familiar with PyPi packages, but I know there are some oddities with - and _, and that they are sometimes supposed to be treated the same, and sometimes not. We don't totally understand all the rules, to be honest (even after reading PEP503 specifications).

In this case, the package is actually websocket_client, not websocket-client.

See: https://pypi.org/project/websocket_client/

When you search for websocket_client in ProGet, it shows up, as expected.

You're right, I guess that's showing the "layers" instead of the "tags"; I think it should be showing container registries separately (they're not really feeds), but that's how it's represented behind the scenes now.

Anyways we are working on ProGet 5.3 now; there's a whole bunch of container improvements coming, so I've noted this on our internal project document, to make sure we get a better display for container registries.

@joshuagilman_1054 I don't really know PowerShell myself (today I learned you can do classes )... but behind-the-scenes it's .NET, and that means we can use nullable value types.

I tried [int?] (nullable shortcut syntax) and [Nullable<int>] (generics shortcut syntax) but PowerShell isn't so happy with either. So the long way it is...

[System.Nullable``1[[System.Int32]]] $myInt = 0
echo "myInt is $myInt "
$myInt = $null
echo "myInt is $myInt "
$myInt = 1000
echo "myInt is $myInt "

That should do the trick for you, and is close to our JSON Model anyways.

Hi @msicc ,

I would definitely budget for ProGet Enterprise, as you 100 devs is generally where a load-balanced setup really starts to make sense. It depends on so many factors, but a handful of simultaneous package restores can yield thousands of simultaneous requests by machines more powerful than a typical ProGet server (i.e. developer workstations), each which generally has to reach to connectors.

That basically leads to a DDoS against your server. See How to Prevent Server Overload in ProGet to learn more.

As for active builds,

• a build is an entry under SCA > Projects > Builds; typically one build per CI run, but you might do more
• only the first 1000 active builds are analyzed; so everything else will show as inconclusive
• you can configure different stages to automatically archive other builds upon promotion; this is what we recommend

To estimate, I would do a multiple of your active, nonlibrary projects. It's certainly feasible to have multiple active builds per project (e.g. one in build stage, one in testing, another in production), but a lot of that depends on your configuration.

Hope that helps,
Alana

Hi @amy.j ,

If the package is already cached in ProGet, then the publish date is already set. So, i would make sure to delete the package and try it again.

Otherwise, can you share more specifics? That way we can create a reproduction case.

Thanks,
Alana

@Nils-Nilsson thank you so much!

We've published a new version of pgutil with these commands added :)

Hi @bobmaurer ,

We recommend to import those packages into ProGet and publish to ProGet going forward.

That keeps ProGet as the source of truth for your artifacts, reduces a lot of network traffic, makes it easier for developers to not worry about multiple sources, and eliminates a lot of possible headaches later with configuration/outages/authentication./etc. Much simpler this way.

Best,
Alana

Hi @brad.zinser ,

This is expected behavior across our products... both the Diagnostic Center and Native API require system/admin-level access, so it's not exposing any information administrators can't already easily see.

Note that, you can also see the API key exposed in standard HTTP access logs as well if you pass via the query string, so the X-ApiKey header may be better anyway.

Thanks,
Alana

Hi @a.sieger ,

I would push back on that "hard requirement" because it doesn't make any technical or business sense, and will only lead to support headaches just like this.

There is something wrong with your PostgreSQL server configuration, perhaps permission related, that's causing the database to not be created. The error cannot be logged in the database because it doesn't exist.

I would delete the database and start again, but verify you've created the database exactly as specified using the exact version supported:
https://docs.inedo.com/docs/installation/postgresql#external-postgres

Things like improper locales will cause errors.

Then, don't run ProGet detached (i.e. ommit -d) so you can get the console logs. That's where you will see database errors. You can also run the upgradedb command instead:
https://docs.inedo.com/docs/installation/linux/installation-upgrading-docker-containers#upgrading-the-database-only-optional

Please let us know what you find!

Hope that helps,
Alana

@forbzie22_0253 yes it's supported, but please note we are moving away from SQL Server to PostgreSQL, so you should consider migrating (Admin > Database)

Hi @a.sieger ,

Please note that we do not recommend an external PostgreSQL database. It performs slower, costs more to maintain, has a higher chance of outages, and tends to cause support headaches down the line. The database primarily stores package metadata and application configuration, doesn't take up much disk space, and it's not the business data that your DBAs would own.

That being said if you really insist on using one, then please refer to the Database Connection String section on the page you linked.

For the non-embedded PostgreSQL database backend, you will need to specify a «inedo-product»_POSTGRES_CONNECTION_STRING environment variable instead.

So you need to use PROGET__POSTGRES_CONNECTION_STRING

Thanks,
Alana

Hi @daniel.mccoy_4395 ,

Actually, developer experience is a big reason we don't recommend using Download Blocking. A 400 error provides no real context. Developers can see something is wrong, but not how serious it is or what to do next.

First and foremost, an unlisted package should not be noncompliant. An author may decide to unlist their package for any number of reasons, including simply not wanting too many versions to show up in a list.

This would mean that, all of a sudden, a build deployed to production can suddenly be considered as noncompliant just because an open source author arbitrarily flipped a switch on NuGet.org. That's not to say you should ignore the unlisted flag, but you should definitely not put it at the same categorization as a GPL3 license or severe vulnerability.

"Compliant with Warning" could be a more appropriate status here, but keep in mind that developers swill naturally upgrade dependencies as they do platform updates, so it may not even be worth worrying about. Especially if it leads to constant warnings -- in that case, warnings become meaningless.

Noncompliant packages should be rare for the same reason. If noncompliant can be determined by an OSS author's whims, then it really caries no meaning and no one (especially your developers) will understand/appreciate what it means.

As for the workflow to use, we recommend running pgutil builds scan when that pull request is run. That will not only put the build in ProGet, but it will produce a text report with warnings or noncompliant packages. A ProGet login is not required.

If there are Noncomplaint packages or warnings, the developer can then comment on the PR why it's nothing to worry about. If it's always the same package/issue ("we cannot upgrade from this 5-year old library and replacing it would be a substantial effort"), then you can formalize that as an exemption.

The advantage to this workflow is that, if a deployed build later becomes noncomplaint (typically due to a vulnerability), then you can decide how and when to address it. The wrong time to address noncomplaint packages is "the next time a developer happens to open this project".

Overall, what you want to avoid is having developers load a project for what should be a trivial change and then have to upgrade dependencies because it produces pointless warnings/errors. That will just create a "constant upgrade" mentality. That leads to constant regressions and constant headaches for testers or end-users, who have to deal with strange and unexpected errors from library upgrades.

Hope that helps,

Alana

Hi @rcpa0,

It's hard to say, but maybe it has something to do with how the package file / archive was created.

Can you share the file or a reproduction case?

Thanks,
Alana