There's no problem in using the legacy features in BuildMaster 6.1.28, though they are a bit hard to find. Our goal was that no new users would see them, but existing users could still access them.

You can directly navigate to the page where these are displayed with /schedules under an application, so for example http://buildmaster/applications/4/schedules. You should be able to also find this page on the Applications > MyApp4 > Settings > Legacy Build Triggers.

The Legacy Build Triggers link will only display when Legacy.ScmTriggers is checked (Admin > All Settings). This should be set if you have them (the legacy feature detector should have checked this, but it might not have).

These are also directly the database, happy to give more insight if you want to look across all apps. I don't believe there was a way to do this globally (but you can for 6.2 / non-legacy).

@harald-somnes-hanssen_2204 that's... a lot of vulnerabilities

I did just want to confirm this bit...

Manually by version, where the version is either removed entirely or unlisted .. very ineffective.

Are you referring to deleting/removing vulnerabilities, or the packages themselves? Are you using "retention rules" to clean-up the old chocolatey packages?

Basically the feature idea I'm thinking essentially a checkbox on the Retention Rules, where it deletes the vulnerabilities when the package is deleted, if no other packages are using it. That seems like the easiest and most explicit way to manage going forward

Thanks @bvandehey_9055 and @harald-somnes-hanssen_2204 !

It's likely not something we can consider in the next quarter (q2) or so, but we can reinvestigate our roadmap as we approach Q3.

FYI @alexjeffreys_3320 this is currently targeting 5.3.26, which is planned for April 2 (PG-1914) - we'll update if it gets tricky or problematic

@nicolas-morissette_6285 ah, that's too bad, but not surprising. Microsoft doesn't like non-Microsoft products (or even products from other departments) using their products

Unfortunately we can't "see" the response or back/forth communication and have no idea what's going on.

You could attach ProGet to a proxy server (like Fiddler) by going to Admin > Proxy, and see what's the back/forth communication is.

Or , easiest thing, just send us an access key to test with. We can just attach a debugger and see the responses, and maybe even fix the code or work-around whatever nonsense they're doing.

If you email it to support at inedo dot com with the [QA-529] in the subject, we can then attach it to the internal issue, and an engineer can investigate.

Thanks @alexjeffreys_3320,

So basically, npm install can fail when you transition projects from npmjs.org to ProGet. I can see that being inconvenient, since you'd have to redo the lock file.

In theory it should be an easy fix to do, right? But just wanted to understand why

We can just use this thread as a feature request, I've already marked it that internally, and it'll get evaluated from here. That'll take a few days, but we'll try to respond within a week about the status! Please stay tuned

@emejibka_8689 got it, thanks!

So, ultimately, you were able to get it working by adding that?

I'd love to get a NGIX Guide together that walks through how to do this. What did your NGIX configuraitn end up looking like?

@antony-booth_1029 we'll try to figure this out!

Did this just start happening? There were some minor changes/fixes to the config file pages in the last release I believe, and it may have impacted this.

Could you check Admin > Diagnostic Center to find the error message and stack trace from this?

Hi @alexjeffreys_3320 ,

Why don't we put together a Feature Request for this?

To start with, how would adding .integrity metadata help? Is this for another tool integration? I understand that sha512 > sha1, but if you've already got a secure connection to ProGet, then you can already trust the packages you downloaded.

Thanks,
Steve

@harald-somnes-hanssen_2204 thanks for the Feature Request, definitely makes sense to me!

Just a couple things to consider / think about, on our end, from an implementation point.

• How do you remove internalized chocolatey packages? Is this using the Package Retention Rules feature? Maybe it would make sense to add a deletion as part of this process.

• How many excess/outdated vulnerabilities do you have now? Handful? Dozens? Hundreds?

I'm not super-familiar with ADO's npm feeds, but I don't think you're the only one who's had this issue, based on this old post.

Since that post was made, we added the "Authentication" drop down, and you should select Bearer for that. Then, keep Username empty.

If you do that, the Password field will be used as the Bearer token.

Can you try taht, and let us know if it works?

@philippe-camelio_3885 this seems to be a regression, but an easy fix. It'll be fixed in the next BuildMaster (6.2.28), but you can grab the patch from here: https://inedo.myjetbrains.com/youtrack/issue/BM-3672

Just download that SQL file, run it in your environment, and they'll start showing again.

Thanks @bvandehey_9055 !

Just a couple questions to help us understand...

• Do you intend to publish your own, first-party packages?
• Are there any other third-party package sources, other than pub.dev?
• Aside from your own packages, what are the main benefits of a private repository for third-party packages?

The recommended private server (https://pub.dev/packages/pub_server) seems to be discontinued and no longer maintained. Are there any other private package server on the market?

This will help us come up with how to evaluate this!