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 @it4it_9320 ,

I was able to reproduce this; it looks like the jammy/main/binary-amd64/Packages index is invalid and duplicates several packages, including this:

Package: aadsshlogin
Version: 1.0.023850001
Architecture: amd64
Section: utils
Priority: optional
Maintainer: Yancho Yanev <yyanev@microsoft.com>
Description: AAD NSS, PAM and certhandler extensions
 This package installs NSS, PAM and certhandler extensions to allow SSH login for AAD users.
Conflicts: aadlogin
Depends: libc6 (>= 2.34), libcurl4 (>= 7.16.2), libpam0g (>= 0.99.7.1), libselinux1 (>= 3.1~), libsemanage2 (>= 2.0.32), libssl3 (>= 3.0.0~~alpha1), libuuid1 (>= 2.16), passwd, openssh-server (>=6.9)
Pre-Depends: grep, sed
SHA256: efad79eb58c10155710ef59171fbe73d67e765a49ce4cc4f4e3622163f4c2f84
Size: 332574
Filename: pool/main/a/aadsshlogin/aadsshlogin_1.0.023850001_amd64.deb

Package: aadsshlogin-selinux
Version: 1.0.023850001
Architecture: amd64
Section: utils
Priority: optional
Maintainer: Yancho Yanev <yyanev@microsoft.com>
Description: Selinux configuration for AAD NSS and PAM extensions.
Conflicts: aadlogin-selinux
Depends: policycoreutils (>=3.3-1), selinux-utils, selinux-policy-default
SHA256: 6a0c3277754585d81d7c1216a23fa034bca6cacef7f162aba0af301ea734fc49
Size: 2214
Filename: pool/main/a/aadsshlogin-selinux/aadsshlogin-selinux_1.0.023850001_amd64.deb

So, as a result, the error occurrs. We will add some checking code for this bad index file, and plan to fix this in the upcoming maintenance release via PG-2834

Thanks,
Alana

Hi @frei_zs ,

Replication uses the package file's hash value, so "new" package files should be transferred when the files are updated. I know a lot of users rely on this behavior, including us every now and then. Debian is a little different than most package feeds because of how the component part works, but it should be the same.

This should be relatively easy to test/verify:

1. Create two two packages (A-1.0.deb, A-1.1.deb)
2. Add a dummy file to the A-1.0.deb archive, save it as alt-A-1.0.deb
3. Create a new Debian2 feed and upload A-1.0, A-1.1; verify feed has two packages
4. Upload alternate A-1.0 file; download the package and verify it's modified and feed has two packages
5. Replicate to a new Debian2 feed; both packages should replicate
6. Upload the original A-1.0 file, and it should replicate within a couple minutes
7. Upload the alt-A-1.0 file, and it should replicate within a couple minutes

If you can reproduce this on a new feed configuration, maybe it's something to do with the package files; can you send them to us? Then we will try to rperoduce in a debugging environment.

Thanks,
Alana

Hi @philippe-camelio_3885 ,

Can you try this on Otter 2023, to see if it makes a difference? We made some Git library changes and that's the easiest thing to confirm if it's related to that.

Thanks,
Alana

Hi @caterina ,

This will be fixed in the next maintenance release via PG-2829. I just checked in the change.

I made a mistake when making the original change, and used the ProjectBuildId instead of the ProjectId when validating the if other builds exists. So it works if the Ids match perfectly (like when I tested it).

Note this only impacts the UI, and we don't really expect users to create builds via the UI.

Thanks,
Alana

@dan-brown_0128 @scampbell_8969 thanks for the feedback!

I've added a note to our internal board for ProGet 2025 roadmap consideration; after we get through the PostgreSQL migratoin, we will likely focus on SCA feature improvement, but maybe there will be room for this.

Any guidance/ideas on the UI/docs would be really helpful when we come to revisit it.

https://inedo.com/products/roadmap

Hi @forbzie22_0253 ,

That's not exposed in the UI at this time; is there a reason/use case you'd want to use it? it's primarily intended as a kind of backup of sorts.

Thanks,
Alana

Hi @davidroberts63 ,

The Projects & Builds page (/projects) requires Projects_View permission.

Cheers,
Alana

Hi @udi-moshe_0021 ,

If you're talking about connecting to DockerHub, the behavior is a little weird... but yes, images without a prefix need the library prefix. This is actually how the Docker client behaves behind the scenes.

When you request ubuntu, the Docker client actually requests library/ubuntu. You can edit the connector (Advanced tab) to automatically add the library prefix, which will behave like the Docker client.

Thanks,
Alana

Hi @udi-moshe_0021 ,

I would suggest using the latest ProGet version.

A "manifest unknown" is a very generic error, and the docker client doesn't log any more details (log, error message from ProGet, etc). I suggest using a traffic capture tool to see exactly what the problem is.

Under the hood, Docker clients can have some problems with proxies, so this could be related. The DockerHub also has rate limiting, so that could be a problem you're experiencing. We just can't see it with just the Docker client sometimes.

Thanks,
Alana

Hi @daniel-lundqvist_1790 ,

You can select the edition you'd like to trial within the software itself, under Admin > License Key.

Thanks,
Alana