Hi @janne-aho_4082 ,

That version will work on 6.0.8 as well! Please let us know, we're eager to get this improved.

Since there's a lot going on, I want to share a summary...

In some maintenance release of v5, we updated Active Directory libraries. Apparently a side effect for your domain was that querying the "memberOf" property of a LDAP user object is really slow. Who knows why.... it makes no sense. But that's LDAP. Anyways, I guess it must not have been noticed from the front-end? Hard to say.

In v6, we redid API authentication. However, we didn't use the LDAP User Cache. We fixed this mostly in 6.0.8, and hopefully fully in 6.0.9-rc.3. That seems like it helped some, but it must be still slow querying the "memberOf" property.

We figured out a way to cache the "memberOf" property, and then applied that to InedoCore-1.13.1-rc.10. So hopefully with the user object cached and memberOf property cached, this should be much faster.

Cheers,
Steve

Hi @janne-aho_4082 ,

No problem, and great you can try this so quickly; PG-2096 is available in 6.0.9-rc.3, and you can install this via the Inedo Hub; https://docs.inedo.com/docs/desktophub-overview#prerelease-product-versions

Cheers,
Steve

Hi @nmorissette_3673,

Unless you blurred out /feeds in your screenshot, the URLS are different:

• Server: /feeds/nuget/Puma.Security.Rules/versions
• Workstation: /nuget/Puma.Security.Rules/versions

Otherwise, I can't help but wonder if there's some rewrite rule, proxy server, or something that's interfering between your workstation and the server

Cheers,
Steve

Hi @martin-noack_4528 ,

This isn't currently supported, in part because it wouldn't be possible to do with cloud storage providers. It also doesn't seem to happen that often, so we didn't implement it.

Is this an operation you'd do often? We can consider adding it, though it wouldn't work for cloud storage because, for whatever reason, the only way to "rename" a folder is by moving each item individually (which can take a long time).

Cheers,
Steve

Hi @claudio_9251 ,

This is most certainly another bug/quirk with Telerik's proprietary feed, and them not following the clear NuGet API specifications

If it's easy we'll consider trying to work-around, but otherwise they really need to be following the API specifications. Or they should migrate away from their own server, like how Infragistics did ;)

Anyway, if you can share the specific HTTP request that is return an unexpected result (it's probably some GET query that returns 404?), then we can try that against the same credentials you sent earlier, and attach a debugger to see what's going on, and if it's an easy fix.

You can find this request by attaching Fiddler, then doing a side-by-side comparison in Visual Studio.

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 @claudio_9251

I believe that Telerik has a buggy/quirky API implementation, and sends invalid/broken metadata. It happens to work in Visual Studio, and I guess an older ProGet.

Anyways, if you can send us some credentials / instructions to connect to your Telerik feed, we will connect and attach a debugger, and trace the bad metadata.

You can email those to support at inedo dot com -- just reference [QA-743] in the subject. And please let us know when you send them email, because we don't monitor that address.

Cheers,
Steve

Hi @mcascone !

Interesting idea . just brainstorming here :)

Can you share the workflow you're thinking? Like... why do you want to know that a package was repackaged/promoted?

For example...

• I already know that a -rc.xyz version has been repackaged, because we only creat -ci.xyz versions.
• I already know that a package has been promoted, because that's the only way these packages are in a feed

... so this information isn't so helpful to me. Unless a mistake was made, only promoted packages are only in certain feeds, and all packages go through same workflow (repackaging).

Thoughts off the top of my head...

• Promotion records exist in the database, so perhaps easier to show
• Repackaging records are inside the package (I think), so maybe harder to show

Cheers,
Steve

@Michael-s_5143 have you installed using the Inedo Hub?

You can change this in the configuration tab. Otherwise, this is in the Installation Configuration Files.

@mcascone thanks so much for confirming that! This may be fixed in v6 already, but I created the issue PG-2072 just in case it's not.

We should get it shipped in the next or folllowing maintenance release.

@mcascone ha! I guess I should say "Onedrive" or whatever it's called -- basically a place to version it as simply as possible.

Just FYI --- we're a pretty small team here, and had that same "gathering dust" worry. But our SOP are a collection of .txt and .ppt files in one of two places:

• "training" folder, which new staff use to follow common process (e.g. change management process)
• "program" folder, which describes a process someone is owns and is responsible or reporting/improving upon (e.g. release process)

It was a little bit of a culture shift for everyone, but now it's great to "not have to think" about the steps (just jump back to the folder), which also benefits new staff learning process (or someone covering for another person).

Hi @harald-somnes-hanssen_2204 ,

Just some random thoughts here...

ProGet has the Package Consumers feature, but that's not quite a traceable a BOM.

We largely see BuildMaster's artifacts and metadata serving as the BOM (several customers implemented it like that), though we don't necessarily call it "software bill of materials". We probably should from a marketing/positioning standpoint :)

There is no format/standard for a SBOM file, but an Asset Directory (and it's directory- and file-level metadata) could severe as such a repository. Universal Packages could as well, but I would imagine a SBOM would be like a XML or JSON file or something.

Steve

Hi @mcascone

Just to confirm, are you referring to this field?

I didn't get a chance to test (want to confirm I understand first), but the "Target Feed" field should be either:

• a be drop down of all NuGet Feeds (when "Promote To Feed" is not set)
• a dropdown of two feeds (current, and "Promote To Feed")

Is that not the case? If not let's get that fixed :)

Cheers,
Steve

Hi @mcascone ,

Thanks for this suggestion, too! Along the same vein as ProGet: Feature Request: native integration with GitHub to perform automated tasks, this is more "process control/workflow management", and not something ProGet is built for.

If you develop a Manual Package Promotions/Repackaging Process (for example, when automation doesn't make sense), then that process should be a SOP document/checklist that lives somewhere (wiki, sharepoint, etc), along side other change management processes.

A bit outside our scope, but I always recommend SOP for organizations of all sizes (even 1). Helps with everything from onboarding to consistency to process improvement. Doesn't need to be anything more than a simple .txt file on Sharepoint with some basic instructions. It can always be improved later.

BuildMaster does have this built-in for CI/CD-related processes, so a lot of SOP we see are mostly "follow the pipeline/prompts in BuildMaster", etc.

Hi @mcascone,

Thanks for the feature request; this type of orchestration is something that should happen by at the CI/CD Pipeline-level, in a tool like BuildMaster.

For example, consider our open-source Inedo.AssetDirectories .NET library (GitHub, Package).

In the corresponding Inedo.AssetDirectories BuildMaster application, when someone promotes the package to Release (see the Deployment Pipeline), the source code is tagged immediately after the promotion:

ProGet::Repack-Package
(
    PackageSource: NuGetLibraries,
    Name: Inedo.AssetDirectories,
    Version: $ReleaseNumber-rc.$BuildNumber,
    NewVersion: $ReleaseNumber
);

... snip ...

# Tag Source Code
# Tag the commit in source control using the id captured in the Build plan
{
    GitHub::Tag
    (
        From: GitHub,
        Tag: Inedo.AssetDirectories-$ReleaseNumber.$BuildNumber,
        Branch: $Branch,
        CommitHash: $CommitId
    );
}

You may be able to do this with ProGet's webhooks, but ultimately ProGet isn't an orchestrator (i.e. it doesn't have an execution/automation engine), and you won't get the level of reliability or flexibility needed.

Hi @shiv03_9800 , thanks for the detailed report on these!

We've identified these as OT-440 and OT-441, and they will be fixed in the next Otter maintenance release (3.0.14), scheduled for tomorrow.

Cheers,
Steve

It seems the package deployment endpoint is POST-only, but using the Native API you could use the Packages_GetPackageDeployments method. Down the line we can certainly consider adding GET method on the deployment api... if you can help us know what you/someone will use that info for ;)

Glad that helped @mcascone , I'll try to update the docs when I get a chance!

In older versions, that information used to be displayed more prominently, but unfortunately relatively few users seem to utilize that data, and several have moved to Package Usage. I think someone even built Usage Scanner that queried that deployment history table but we couldn't get much info beyond that...

We don't maintain that Jenkins plugin, but it is open-source and if you're comfortable enough with Java you might be able to add the required header fields?

https://github.com/jenkinsci/inedo-proget-plugin/blob/master/src/main/java/com/inedo/proget/api/ProGetApi.java#L189

But you may find upack.exe to be better, since it can "install" packages, which then maintains a history on the server itself.

Hi @mcascone ,

These are two different features...

Deployment records show which servers a package has been deployed to from that instance of ProGet, at some point in the past. They are usually added when a package is downloaded, and the GET request has a special header parameter or a user agent string.

Package usage is more complex, in that it shows which servers/hosts a package (or container) is currently installed on, regardless of whether it was deployed from ProGet or not. It requires a PackageContainerScanner component, which is intended to bridge the gap between servers and packages.

We currently have two scanners: one that interacts with Otter's API (which can return Docker, Debian, Rpm, Universal, and Chocolatey packages across your servers) and Kubernetes API (which is just Docker and Helm charts).

Hope that helps,
Steve

@mcascone yep, that's a good way of putting it!