Hi @mcascone ,

We don't have a single API method that can be used to delete all package versions from the API, but the foreach loop will do the trick!

I should add that I am doing this as the first stab at an attempt to automatically delete packages from a development feed, when the corresponding branch in github is deleted

I don't know the specifics/details of your use-case, but based on what I read, I'd recommend these guidelines:

• assuming: one GitHub repository, one project, one package you want to release
• use the same package name/group for all packages you create for this project, regardless of branch or development status
• create your "dev" packages using a prerelease version number, that has a sort of -ci.## version (assuming you use CI to build packages)
• embed the commit id and branch in your upack metadata file, for traceability
• if you want to see which branch the packages was created from using the version number alone, add a +branch metadata label to the version number for branches (don't do this for master)
• use repackaging and promotion to take your -ci packages to -rc to stable (and the desired feed)
• let retention policies automatically cleanup up the -ci packages

Hi @kichikawa_2913 ,

I think it's this way for "historic reasons" - mostly all the other feed types came later, and it seems no one ever changes these paths or noticed.

Easy enough to make it configurable, but can you share your use case? Why do you want to use something other than a single root path with all of your packages?

Anyway I added a feature for this, and we should be able to get it in the next maintenance release PG-2006

Cheers,

Steve

Hi @benjamin-soddy_9591,

No problem "resurrecting" topics! We definitely want to hear from users about feedback/feature requests.

We still haven't had anyone else ask for deprecation since this request, but I wonder if there's a better solution to solving your challenges than this feature. It sounds like you want to increase governance of your NuGet Packages, potentially with some sort of compliance in mind.

The dotnet list package --vulnerable is probably not what you want for your organization; NuGet's Built-in Vulnerability Scanning is really limited, in part because it only reports on a fraction of known package vulnerabilities (164 as of today). It also won't block packages that you deem problematic, unlike ProGet's feature.

The same is true with dotnet list package --outdated -- it's probably not what you want, because it relies on developers to have to know (1) to run the command, and (2) know what to do if there's an outdated dependency.

There are better ways to manage third-party packages (see How to Create a Package Approval Workflow for NuGet), and you'd better served knowing who's consuming outdated packages (see Use Package Consumers to Track Dependencies

Just some thoughts; like I said, we haven't had any demand for this feature, but these are proven solutions for improving governance of packages as organizations grow/expand their NuGet usage like you are.

Cheers,
Steve

Hi @kichikawa_2913 ,

The NuGet client's behavior is based on NuGet.org, where no authentication is ever required to view/download packages. As such, it doesn't pass the API key when doing those queries; instead, you can use a username of api and the password of your api key.

Based on the issue though, it sounds like ProGet is unable resolve the groups; I would use the "test privileges" function on the Tasks page to verify this. Thatw ill show you if the username can download packages or not.

The most common reason that groups aren't resolving is that the member is not directly in the group (i.e. they're in a group which is a member of the group), and you don't have recursive groups enabled; do note that this is really slow on some domains.

Cheers,
Steve

Hi @mcascone ,

Just looking at the code real quick, I suspect we have a bug where it writes out the wrong files name for the new package:
https://github.com/Inedo/upack/blob/master/src/upack/Repack.cs#L120

That's probably an easy fix, which we can do as part of this Q&A item. I'll wait to hear back about this one.

As for the error, "The underlying connection was closed: An unexpected error occurred on a send.", that sounds like it's HTTPS related. Could you attach Fiddler, or something like that, to find out what's happening under the hood? We may be able to error message to better report it if so.

Cheers,
Steve

Hi @cimen-eray1_6870 ,

Great questions; there's no problem having a second instance with ProGet Free Edition.

The relevant restriction is that you can't use a Connector in ProGet Free Edition to connect to another instance of ProGet (either another Free Edition or your paid edition).

Hopefully you can use your Maven feed as a proof of concept for implementing it in the main instance. Good luck!

Cheers,
Steve

Hi @brett-polivka,

I've added it to our Other Feed Types page, and linked this as the official discussion thread.

There's a lot of things to consider in developing a new feed type, but ultimately it all comes down to two things: (1) how much more value does this feature bring to our users, and (2) how many new licenses of ProGet would this feature sell.

The second question is where internal market research comes in, but we would love your opinion on the first question.

Here's a nice and simple way to help understand value: how much more do you suppose your company/organization would pay for this feature if it were available as a hypothetical add-on? $100/year? $1,000/year? $10,000/year? Etc. And why? What time is it saving, risk is it mitigating, etc.

The second part of the value equation is how much effort will it take, technically speaking. It's more than 15 minutes obviously, but is it 10 hours? 100 hours? Etc.

On the plus side, the package format seems to be documented pretty well. However, the registry API has a huge red flag:

The index key should be a URL to a git repository with the registry's index.

Does this mean their API is Git-based, and we'd need to first add private Git repository hosting to ProGet? And did they test it with private/authenticated Git repositories, or just their public (probably GitHub) repository?

@stefan-hakansson_8938 as you noticed, ProGet's Debian connectors are not currently designed to handle the gigantic, operating-system mirrors very well. This is because they are always refreshed "on demand" - which is what you want for CI/CD workflows.

It's not great for public repository mirroring, however. In Q4 or later, we will explore adding an option to do periodic updates.

Hi @m-webster_0049 ,

The first thing I would try is to troubleshoot this is to switch to a very basic API key like hello. That just eliminates any typos, spacing, etc.

Next, I would try specifying the API Key via X-ApiKey header (see docs) - just to see if you get a different error. It's possible there is a regression somewhere.

Best,
Steve

@joshuagilman_1054 this is currently planned for 5.3.27 as PG-1934 (April 17) - we'll let you know if plans change!

Hi @jlarionov_2030,

I haven't tested or tried it, but I can't help but wonder the API is responding with some kind of "license required" error, and blocking the seting.

I suppose we could investigate and try to resolve the error, but automated setup with a license key isn't so common of a requirement.... if tis is not really something you will do that often, perhaps it's not worth the effort.

Let us know your thoughts.

Thanks,
Steve

Hi @jlarionov_2030 ,

As of ProGet 2023 (or maybe earlier?), license keys are no longer requested / entered at installation time, but in the software itself now. This only matters on new instances.

You can use pgutil settings to set a license key if you'd like.

Thanks,
Steve

Hi @parthu-reddy,

Thanks for discovering/confirming that; unfortunately we're not able to reproduce this issue, as the multi-part / chunked uploads already take into account multiple servers.

• Chunked upload sessions are persisted in the shared database (ChunkedUploads table)
• Bytes are appended to a file stored in shared store

Would you be able to dig into the request patterns a little more? I suspect there's "something" configured on the load-balancer that's "doing something weird" with these ranged requests.

The Multipart Upload API explains what's happening behind the scenes, and you may find that using pgutil assets upload is easier to troubleshoot.

Thanks,
Steve

Hi @jw ,

It definitely looks like there's some "drift" in the documentation and behavior. I already see some stuff about "allowedFeeds" in there, which isn't even a thing since policies. And you're right, you can't update code/title, which aligns with the pgutil behavior as well.

We'd rather have "no documentation" than wrong documentation, any suggestions on what to delete from here? https://github.com/inedo/inedo-docs/blob/master/Content/proget/api/licenses/update.md

Feel free to submit a PR if you've got a clear idea.

In general, we want to make sure the pgutil docs are accurate (those are very easy to test), and we figure... someone can just look at the pgutil code to learn the HTTP endpoint or library.

Thanks,
Steve

Hi @udi-moshe_0021 ,

My guess is that your proxy server is blocking certain things or having issues with redirects; you'd really have to monitor the back-and-forth traffic to see what's going on.

As you can see, there are a lot of "redirects" going on and URLS/Domains that you will not expect and can be hard to predict.

Thanks,
Steve

Hi @it_9582,

First and foremost, we don't recommend the "package promotion" feature as a means to indicate which "stage" (i.e. tested quality) a package is in relative to a CI/CD pipeline.

Instead, repackaging should be used:
https://docs.inedo.com/docs/proget/packages/repackaging

Having multiple feeds is fine; we do that for Products and PreReleaseProducts on proget.inedo.com, but that's to make it "harder" for someone to accidently use a prerelease version. Otherwise, you can just use one feed and have retention policies cleanup the "-ci" builds.

As for having the "build promotion" feature in ProGet be used as a workflow engine (i.e. to trigger actions upon promotion), I don't think we would consider that. At the most, we would do a webhook of sorts... though it doesn't make a ton of sense to be honest.

The reason is that ProGet isn't intended as the "source of truth" for build status - the idea is that you would have something like a pipeline in BuildMaster) update the statuses in ProGet.

The main benefit to having this status in ProGet is retention of builds/SBOMs.

Hope that helps,
Steve

Hi @it_9582 ,

You can specify licensing information in the description or in a custom metadata field like _licenseCode or something. It's not something that ProGet "reads" or "understands", mostly we didn't imagine users would package and upload third-party content with unwanted licenses.

If that's a use case that your mid/long-term implementation, we could definitely explore working together and properly adding/supporting it as a feature. It's not something we'd want to just "quickly throw in" from a forum post :)

Definitely chat with your account manager / point of contact once you're closer to or past the "purchase" side of things and we can make it happen. I've forwarded this message to him as well.

Thanks,
Steve

Hi @mickey-durden_1899 ,

Just to double check, can you try.... resetting to disk-based storage, reconfiguring cloud storage, and then making sure that DisablePayloadSigning is checked. And tehn open settings, to make sure DisablePayloadSigning is checked and stays checked.

Thanks,
Steve

Hi @alexvanini_5999 ,

I would try using the Inedo Agent instead; if you are getting this error, it most certainly means that there is some kind of security/hardening/account setting that is blocking WinRM. This is the underlying technology that PS Remoting and the PowerShell-based agent use.

In this state, it's a real pain to get working - and the Inedo Agent is much more stable, anyway. It will not be "randomly blocked" by a new GPO or Patch Tuesday bug as we've seen a lot with WMI.

Otherwise, you'll need to scour the web for obscure settings that may have been applied to the server. You may see information logged on the target machine under Windows Event Log under Windows Logs → Application or System related to WinRM.

It's possible that the domain account lacks needed rights, even though it's a local admin. Sometimes subtle rights (like SeRemoteInteractiveLogonRight, etc.) can block initialization.

Good luck, let us know what you find!

Thanks,
Steve

Hi @jw ,

I'm not able to reproduce any issues on my end; I'm not entirely sure how you're testing, but let me share with you the code on the server side in ProGet:

    private static async Task UpdateLicenseAsync(AhHttpContext context, LoggedResponseStream output, WebApiContext apiContext)
    {
        EnsureMethod(context, "POST");
        EnsureCanManageLicenses(apiContext);

        var input = await JsonSerializer.DeserializeAsync(context.Request.InputStream, LicenseApiJsonContext.Default.LicenseInfo, context.CancellationToken)
            ?? throw new HttpException(400, "Expected license object.");

        var license = await DB.Licenses_GetLicenseAsync(External_Id: input.Code)
            ?? throw new HttpException(404, "License not found.");

        List<int>? nameIds = null;
        if (input.PackageNames?.Count > 0)
        {
            nameIds = [];
            foreach (var n in input.PackageNames)
            {
                if (!PackageNameId.TryParse(n, out var nameId))
                    throw new HttpException(400, $"Invalid package name: {n}");

                nameIds.Add((await nameId.EnsureDatabaseIdAsync()).Id!.Value);
            }
        }

        List<int>? versionIds = null;
        if (input.Purls?.Count > 0)
        {
            versionIds = [];
            foreach (var v in input.Purls)
            {
                if (!PUrl.TryParse(v, out var purl))
                    throw new HttpException(400, $"Invalid purl: {v}");

                versionIds.Add((await ((PackageVersionId)purl).EnsureDatabaseIdAsync()).Id!.Value);
            }
        }

        await DB.Licenses_UpdateLicenseDataAsync(
            License_Id: license.License_Id,
            PackageVersionIds_Csv: versionIds?.Count > 0 ? string.Join(',', versionIds) : null,
            PackageNameIds_Csv: nameIds?.Count > 0 ? string.Join(',', nameIds) : null,
            SpdxIds_Csv: input.Spdx?.Count > 0 ? string.Join(',', input.Spdx) : null,
            Urls_Csv: input.Urls?.Count > 0 ? string.Join(',', input.Urls) : null
        );
    }

I'm not sure if that's helpful, but if not... can you put a specific reproduction case?

Also note that the license data in the UI is cached, but it's invalidated when you visit the /licenses page and others.

Thanks,
Steve