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 @michal-roszak_0767 ,

401/403 are not logged, so you won't see a server side event.

403 means authentication was successful but the permissions are not OK

My guess is that the wrong feed or credentials are being specified. Like maybe using an API key?

Thanks,
Alana

Hi @michal-roszak_0767,

I'm not sure, but maybe it's something simple like a typo. I don't see it though.

That 401 message will occur when credentials weren't sent.

Behind the scenes, pgutil uses that API and authenticates by adding the same header:
https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/ProGetClient.cs#L37

Perhaps you can use a proxy like Fiddler or ProxyMan to see the difference in HTTP Traffic?

Thanks,
Alana

Hi @bill-hertzing_2810,

It sounds like you want to enable API v3, which uses the `v3/index.json' URL suffix?

In that case, make sure to set the useApiV3 property is set. Also, I don't think you can set all those properties on create... you may have to create, and then update.

Also note that you cannot set the endpointUrl property, it's just readonly. That is generated based on the incoming reques, so if you're viewing it on localhost you'll see that. If you view it on myserver.corp you'll see that, etc.

Hope that helps,
Alana

Hi @parthu-reddy ,

This looks more related to Server Overload / Database than anything to me. Note how all the requests are coming in at exact same second. Can you throttle your load balancer a bit, so they don't all hit at the same time? Even a slight delay will help.

FYI - we are tracking a recent regression to SQL Server analysis engine (???) that is causing one particular query (NuGet_GetPackage) to go incredibly slow under extreme traffic. For some reason, it's using the wrong plan suddly. It's been happening to a few users after a recent upgrade/patch to SQL Server. We have a work-around but would like to test it in the field against a user.

Thanks,
Alana

Hi @marc-ledent_9164 ,

This is available in InedoCore-3.0.4, so if you go to Admin > Extensions, you should be bale to update.

thanks,
Alana

Hi @mhelp_5176 ,

I haven't investigated BitBucket Cloud any further, but it sounds like there's an issue with the integration -- and it's definitely something we can look at later. My guess is that it's some kind of change to the API/authentication. But we're all pretty focused on getting ProGet 2025 out the door, so it'll have to be after that.

That said, the main difference between connecting to a "Git host" like GitHub, GitLab, Gitea, BitBucket, etc. vs a "generic Git repository" is that there will be some intelligent drop downs to help you select a repository. There are a few other differences as well, but mostly it's UI.

So for example, on a GitHub connection, you'll see a list of organizations and repositories, and then would select the one to connect to. Compare this to the "Generic Git repository", where you simply paste in the repository clone url.

But in either case, you need to configure each repository connection individually; typically each application will have one repository, which is why this is part of the application creation process.

It's definitely not a common practice to be able to "pull in all the repositories in a workspace" at once - that's not really how Git works, and it would involve some kind of script that iterates a list of repositories and clones/updates each one indivdiaully based on configured remotes in subfolder.,

Cheers,
Alana

Hi Fritz,

Thanks for reporting this; the underlying with the Packages index file isn't so much the migration, but the code that generates the index file on the new feed.

Basically, the control files seem to be have an extra new line that isn't being trimmed. The old feed code must have removed them.

Anyways we will address this via PG-2985 in the next maintenance release or you can try the proget.inedo.com/productimages/inedo/proget:24.0.37-ci.2 container now.

Cheers,
Alana

Hi @michal-roszak_0767 ,

Looking over the code, the API Key Access Logs contain the api-key sent by the user, which is being displayed there. In retrospect, this isn't a great design...

It would be technically possible to link that to the "Edit API Key Page" itself, which would show you the description etc.... just a matter of whether that's worth us doing.

Thanks,
Alana

Hi @mhelp_5176,

Based on the error, it sounds like there is some kind of configuration error / invalid response coming from the BitBucket Cloud API. It's possible the API/authentication policies changed -- we honestly don't really test against BitBucket Cloud, just BitBucket Server.

How about just using a Generic Git Repository? That uses a different API (the Git API) , so that might just work simpler/easier for you.

Thanks,
Alana

Hi @marc-ledent_9164 ,

Yes, it's a somewhat common configuration; I would go to Admin > Security, and you can add a new directory/domain connection. Note you'll need information like a domain host, name/password, etc.

Thanks,
Alana