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

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?

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

Hi @pbspec2_5732 ,

The script in the linked gist should fix the problem for you; it's not feasible/possible to try editing in the database directly due to the complexity of the model.

https://gist.github.com/apxltd/351d328023c1c32852c30c335952fabb

Thanks,
Steve

Hi @r-vanmeurs_4680 ,

This is a false positive and you can disregard it; ProGet 5.2 is not impacted by the vulnerability in JQuery for may reasons, including the fact that they vulnerable code is not used and, if it were, ProGet is protected on the server-side from such "attacks".

Thanks,
Steve

Hi @arkady-karasin_6391,

What are you specifying for Distribution in the connector? When I tried these settings, it worked:

You need to specify one of the available distributions, which are listed here:
http://archive.ubuntu.com/ubuntu/dists/

Thanks,
steve

Hi @caterina,

We haven't thought of adding a --stage option to the pgutil builds scan command, but of course it's possible. I know that we are exploring other options like associating builds/projects with pipelines (i.e. a sequence of stages).

So perhaps that would mean, pgutil builds scan --workflow=MyWorkflow, and then MyWorkflow would start/end in different stages.

For now, we'd love to see how you utilize the stages. Maybe it means calling two commands temporarily, and we can revisit once we add new features, etc.?

For the pgutil builds create command, the project must already exist, or you'll get that error. You can create or update a project using pgutil builds projects create.

So basically, these command would probably do what you want?

pgutil builds projects create --project=BuildStageTest
pgutil builds create --build=1.0.0 --project=BuildStageTest --stage=DesiredStage

Note that when using pgutil builds create, you can also specify a stage name, like in the example above.

Hi @arunkrishnasaamy-balasundaram_4161 ,

Thanks for clarifying!

[1] The MavenIndex file is not at all required to download artifacts from a remote Maven Repository nor to see the latest version of artifacts. In ProGet, all this allows you to do is browse remote artifact files in the ProGet UI which typically isn't very helpful.

[2] It's not possible to change this

[3] ProGet does not have "group repositories", but uses feeds with connectors. The model is different, and feeds with connectors will often cache packages
in a lot of organizations.

[4] It's likely you will be unsuccessful in your ProGet configuration with a setup like this or at least give your users a big headache and lots of pain/confusion. This is considered an "old mindset" the for configuring artifact repositories that were based on "files and folders on a share drive" not packages.

This "closed approach" will greatly slows down development, causes duplicate code, and lots of other problems. Modern development approaches do not use this level of highly-granular permission. Instead, they take a innersource model. You do not need to make everything available to everyone.

However, less than 1% of your 2k projects will contain sensitive IP or data that other teams can't access - those projects should be segregated into sensitive feeds. The logic is, "if everything is sensitive, then nothing is sensitive"

[5] ProGet does not generate a "support zip file"; if we require additional information when supporting users we ask for the specific information

Hi @uvonceumern_6611 ,

Thanks for providing all of the additional information; based on what you shared, it looks like the file is actually being uploaded incorrectly... using a "multi-party / form upload encoding" instead of a basic PUT of POST of the body contents.

Please see the Upload Asset File documentation for more information.

Thanks,
Steve

Hi @arunkrishnasaamy-balasundaram_4161,

I'll do my best to answer these!

1. You can configure the FullMavenConnectorIndex job to run a routine basis under Admin > Scheduled tasks; it's not enabled by default because the MavenCentral Index is very large

2. I'm not sure what "Context path" means?

3. I'm not sure what you mean by "Group" repo?

4. The way to handle this in ProGet is by using Policies & Rules to define noncompliant artifacts; certain versions of log4j would be considered noncompliant because it has that severe vulnerability

5. We do not recommend 2000 feeds in any scenario; I wonder i there's a disconnect between what a "Feed" is and what you're looking for. A feed is place where you store all of the artifacts for a division/group of projects. The volume isn't a problem, but even a massive organization should have dozens of feeds at most

6. This should show on the "History" page

7. There is the "Packags" page at the top that can do some cross-feed searching

8. Yes; see https://docs.inedo.com/docs/proget/administration/retention-rules

9. I'm not sure what a support zip file is.

10. In general you would follow the migration guides we've published; however, your existing artifact server may not be configured to allow importing. If you're running into issues, best to open a new thread on the forums and we can review/investigate

11. Yes; see https://docs.inedo.com/docs/proget/replication-feed-mirroring/proget-howto-utilize-feed-replication-for-disaster-recovery

12. Yes.; see https://docs.inedo.com/docs/installation/high-availability-load-balancing/high-availability-load-balancing

Hope this helps point you in the right direction,

Steve

Hi @husterk_2844 ,

I'm afraid we're at a loss here; no one else has reported any kind of errors like this, and I can't imagine what would even cause such a problem.

I suspect there is something off about your Docker Compose file? That seems to be the only thing different than the basic setup.

I would just try to re-follow the basic instructions we posted:
https://docs.inedo.com/docs/installation/linux/docker-guide

That's what we use to test, and lots of users install and upgrade without a problem.

Thanks,
Steve

Hi @forbzie22_0253,

There's no Windows event logged, but once the /heath page is reachable, then the application is ready. If you're using SQL Server and IIS on the same box, then both of those must first load before ProGet can start.

Thanks,
Steve

@v-makkenze_6348 whoops, good catch - yes thank you :)