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 :)

Thanks for the update! I've noted this in the docs, and linked to this discussion :)

https://github.com/Inedo/inedo-docs/commit/d24087911584bbda833314084a58c2ae1ff41c39

Hello,

That API will only delete package metadata from the database, not from disk. It's mostly intended for internal use only, and probably shouldn't be exposed to the API. In any case, we don't store the @ with internally, so if you change @myscope to myscope it should work.

Note that the NPM doesn't provide a way to delete packages, and we never implemented it. There hasn't been any demand for it to date, as people don't really delete packages programmatically - but you're definitely welcome to submit a feature request and help us understand why it'd be a value (like, the workflow you use that requires deleting packages, etc).

Alana

Hello, for sure!

It's pretty easy; just don't give the Anonymous user any access to your feeds, and then authentication will always be required, either when browsing the ProGet application or using the API (such as Install-Module).

When you use the Register-PSRepository command, you can the Credential option to specify a credential.

This credential can be the name/password of a user inside of ProGet (let's say, Admin:Admin), or it can be username of api with a password of an api key you've configured (so, api:my-secret-key).

Hello;

The Native API is for low, system-level functions, and it's "all or nothing". If you give someone access to Native API, you are effectively making them an administrator, as they can also change permissions and grant admin privileges. So, I don't think you want this. Instead, you'll want to use the Debian API endpoint that we implement.

It's a third-party API format

In order to support third-party package formats types like NuGet, npm, etc., ProGet implements a variety of third-party APIs. We only provide minimal documentation for these APIs, as they are generally either already documented elsewhere. However, you can generally find the basics by searching for specific things you'd like to do with the API, such as "how to search for packages using the NuGet API" or "how to publish an npm package using the API".

So in this case, I recommend to search "how to view and download apt packages".

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.

In ProGet 5.3, we plan to have a couple tabs on each Tag (i.e. container image) that would provide this info: Metadata (will be a key/value pair of a bunch of stuff), and Layers will show details about each of these layers.

That might help, but otherwise, we have retention policies which are designed to clean up old and unused images.We'll also have a way to detect which images are actually being used :)

As @apxltd mentioned, we've got a whole bunch planned for ProGet 5.3.

I've logged this to our internal project document, and if it's easy to implement in ProGet 5.2 (I can't imagine it wouldn't be), we'll log it as a bug and ship in a maintence release.

Do note, this is not an IMAGE description, it's a REPOSITORY (i.e. a collection of images with the same name, like MyCoolContainerApp) description; so this means the description will be there on all images/tags in the repository.

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.

@Stephen-Schaff thanks for the bug report, I verified that this may happen depending on permission of user, and which feeds they can/can't use --- but it seems an easy enough fix that we can do via PG-1894 (targeted to next release) - the packages can't be viewed upon clicking, but it's a sub-optimal experience for showing packages they can't see

Hi @Nils-Nilsson ,

It's possible but it's quite complex; there are dozens of variable/macros that rely on context (some will give an error) and none of them have built-in dummy data. That would make templating expressions like <% if %> or <% foreach %> difficult to test.

In theory, you could enter a large box of variable expressions (like $FeedName=fake-feed)... but at that point, it's just easier to test things by performing the actions on a real package. A quick pgutil packages delete + pgutil packages upload script works great for that... that's how we test.

Thanks,
Alana

Hi @joris-guex ,

Thanks for the detailed information; I was able to reproduce the error pretty easily thanks to that.

It seems to be happening when parsing a Dependency entry in the .toml file (missing version), but I can't figure out why since the version appears to be there. It also shouldn't cause this beahvior for this particular error.

In any case, we'll get it fixed via PG-3303 in an upcoming maintenance release. !

Cheers,
Alana

Hi @brandon_owensby_2976,

It's a bit confusing, but the message "{name}" is not a valid DeploymentScript identifier for the "global" scope. will occur when:

• a script is being executed in the global context (as this is case here)
• the {name} does not start with global::

I know you mentioned you pre-fixed with global::, but these scheduled jobs can be a bit tricky to test. It's possible that the old record (without global::) was queued up.

To be totally certain next time, I would stop/start the service so that there's nothing that gets queued up.

Thanks,
Alana

@Ashley thanks for letting us know!

Hi @brandon_owensby_2976 ,

Thanks for the feedback, we appreciate it :)

There's definitely a value in building before merging; if you haven't already, I'd check out that feature branch article, as it outlines the pattern we use for it.

In general, the way I would try to configure is:

• consider using a releaseless-build if you don't yet know the release it's targeting
• use a different piepline so it's visually clear; the stages may be Build -> Test -> Merge
• clean up the builds aftewards

That said, this isn't the most popular workflow in BuildMaster, so it may not be the most intuitive to implement or feel a bit clunky.

We don't have a lot of public examples, but the inedo-docs application is the closest to a Gitflow, releaseless type of workflow. Commits to master branch auto-deploy to live site, where as branches can only go to test:
https://buildmaster.inedo.com/applications/136/overview

No idea if that's helpful, but just FYI

Cheers,
Alana

Hi @brandon_owensby_2976 ,

Looks like this is a regression in BuildMaster 2025 from a library upgrade; we will address it via BM-4017 in an upcoming release, either this Friday or the following cycle.

Thanks,
Alana

Hi @pg_user_8607 ,

Nice find with that image; that makes it easier to demonstrate :)

This is unfortunately another "weird docker thing" that would requires a substantial amount of internal model changes to properly address. That's not on our roadmap at this time.

The image you found (inedo/buildmaster:25.0.12) is a so-called "fat manifest" (i.e. a manifest that points to another manifest). As such, there are zero layers (blobs) and thus the sum of all blob sizes is zero.

The 25.0.12 manifest points to e84148156b3e, which is an untagged image. You can see this on the "Sub Images" page:

The /containers page does not show untagged images.

In the past, "fat manifests" were rare - but the default Docker build tools default to create fat manifests, even if there's only one image. It's something we will likely address down the line, it's just not in the roadmap now.

Thanks,
Alana

Hi @brandon_owensby_2976 ,

I'm not sure how easy it will be to replicate that UI and workflow of your current system. It sounds like you're doing some version of "Gitflow", where the "main" branch is "production-ready" and release-candidate builds are "chosen" from that.

BuildMaster uses a different workflow. As you may know, the BuildMaster model uses a Release as a logical set of Builds, with the intent that a single Build within a release will make it to production (final stage). Here's the article that explains is a bit more clearly:
https://docs.inedo.com/docs/buildmaster/modeling-your-applications/buildmaster-releases

Jenkins (and Gitflow) in general does not model Releases in this manner. Instead, it only has "builds", and a build is either a feature branch or a main. And the main build is what eventually gets deployed using a separate job, after a release engineer "picks the build they want" from a list of "main" builds.

The closest way to model this workflow in BuildMaster is to use release-less builds. In BuildMaster, the "Builds" listing will show the branch that is associated with the build, so you can easily see "main" and "branch" builds.

However, this is working a bit against the grain; Releases are a superior workflow model and solve a lot of business problems that Gitflow and "picking from a list of main builds" causes: https://blog.inedo.com/lean-platforms/releases

Here is some notes on our pattern for handling feature branches:
https://docs.inedo.com/docs/buildmaster/builds-continuous-integration/buildmaster-ci-git-workflows/buildmaster-git-feature-branches

Cheers,
Alana

Hi @pg_user_8607 ,

Thanks for the bug report; this will be fixed via PG-3296 in the next maintenance release (scheduled next Friday). It was a problem in the redirect to the /log-in page, so of course if you log-in first, the error will not occur.

Cheers,
Alana

Hi @aristo_4359 ,

We didn't make any changes to LDAP/AD in ProGet 2026; the issue mentioned in the post was more of a display/widget issue (from a UI library upgrade).

Unfortunately we don't have enough to go on to help troubleshoot this nor do we have any other users who can reproduce this. In addition, API keys and Active Directory are separate authentication methods altogether.

There were also no changes to API keys... so it's very possible this is something else altogether,
such as a temporary AD lock out or user configuration issue. We see that quite a lot.

Otherwise, since it's only impacting you and we can't reproduce it, you'll have to simplify the reproduction case to isolate exactly what's happening.

I would try upgrading again, and then going to Admin > Security and using the AD test tool. For the API key issue, I would use a tool like Fiddler or Proxyman to capture HTTP traffic, so you can see exactly what requests are being issued and failing.

Cheers,
Alana