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

@jonathan-werder_8656 great point, we'll add that to our list to document! Thanks for pointing it out

Hi @koksime-yap_5909 ,

As long as the cluster can access the internet (our activation server), the license key should be auto-activated without noticing. This document explains the activation process a little further:
https://docs.inedo.com/docs/myinedo/activating-a-license-key

Help that helps,

Alana

Hi @kquinn_2909 ,

The "Recent TeamCity Builds" page should show a list of builds in the selected TeamCity project; it's a bit tricky to troubleshoot, but BuildMaster is essentially querying for builds using this locator string: defaultFilter:false,project:{Uri.EscapeDataString(project)}&fields=build(id,number,status,state,webUrl,startDate,buildTypeId)

Might be easier to see in the source code:
https://github.com/Inedo/inedox-teamcity/blob/master/TeamCity/InedoExtension/TeamCityClient.cs#L63

I believe the Project ID is being used, which in your case would be WebProjects_Replicator. I think the name would be "WebProjects Replicator". Though I'm not totally sure.

What builds do you see on the TeamCity side of things?

Thanks,
Alana

Hi @jw ,

Thanks for finding this; we'll get it fixed via PG-3180; it was problem when updating the vulnerability database and related to the case matching again. Hopefully this is the last place.

Thanks,
Alana

@kinedax339_3276 great news!! Appreciate the help

Thanks @kinedax339_3276, that was really helpful!

Easy fix to the regex, and I made sure the following work

• http://localhost:8624/cargo/pants/1/a
• http://localhost:8624/cargo/pants/2/cc
• http://localhost:8624/cargo/pants/3/s/syn
• http://localhost:8624/cargo/pants/an/yh/anyhow

Before, the first two returned the same 404.

Anyway this change should be in image 25.0.17-ci.7, which is building now! hopefully this will do the trick

@kinedax339_3276 thanks for checking!

Maybe it's a similar issue.... but honestly I've never used /crate before myself. There's a lot of overhead in figuring all that out for the first time.... so if you can find the URLs being invoked I could probably track it down really easily.

Is ther ea verbose mode we can see that shows urls ?

Here are our internal API notes on the implemented endpoints:

GET /config.json [CargoIndexHandler]
- generates a config.json file
  - "dl" - download URL for crates
  - "api" - API base url for the Web API
  - "auth-required" - boolean indicating if authentication is required to access the registry.
    - This is determined by if the feed has anonymous access for Feeds_DownloadPackage.

GET  /crates/{packagename}/{version}/download [CargoIndexHandler]
- Downloads a crate
  
GET /{prefix}/{packagename} [CargoIndexHandler]
- Downloads basic package version information
- Not true JSON, but each line is a JSON object representing a package version

Maybe it's that last one, with the {prefix} , since those were wrong elswhere. Maybe the matching regex is off?

    [GeneratedRegex(@"^(1-2)/(?<1>[^/]+)$|^(3)/./(?<1>[^/]+)$|^(?![1-3]/)../../(?<1>[^/]+)$", RegexOptions.ExplicitCapture)]

Cheers,
Alana

Hi @kinedax339_3276 ,

It looks like this is an error with the sparse index parsing for short names (e.g. a goes to
https://index.crates.io/1/a, cc goes to
https://index.crates.io/2/cc, syn goes to https://index.crates.io/3/s/syn, etc). Easy fix, we'll get it via PG-3177 in the upcoming maintenance release (Dec 19).

Or you can use the prerelease container image (25.0.17-ci.5) which is being built now.

Thanks,
Alana

Hi @rhowell_8827,

Looking at the code in both ProGet and pgutil, it looks like that simplified upload API only supports the distribution argument. We'll add component in the same manner via PG-3172 in an upcoming maintenance release -- ideally next Friday (should be relatively simple).

Thanks,
Alana

Hi @steviecoaster ,

Nice suggestion; I made a small change and you can now do pgutil apikeys create feed --feed=* to create such a key.

Thanks,
Alana