Topics created by jw

Hi @atripp, We haven't updated the production instance to the version that introduced this feature yet, so nobody breathing down my neck. ;) I'll wait for the official release, but thanks for the offer. Have a nice weekend!

Ahh, took me a while to get it, but this is the dialog I was looking for. It wasn't quite clear that the orange "Package Status is Deprecated" is actually a policy violation dialog, which is overriding this one here. Thanks again.

Hi @rhessinger Works like a charm, thanks. Have a nice weekend.

Hi @jw , This doesn't seem like a a trivial change, due to the way those pages work, so I'll add it to the "wishlist" - we've got a lot of other ProGet 2025 roadmap stuff prioritized ahead for the time being :) Cheers, Alana

Hi @stevedennis Let's continue this thread here: EDO-10681

Thanks for the feedback and the fix. Have a nice weekend.

Thanks for the quick fix. We didn't have that many packages assigned to the licenses in question, so the workaround of disconnecting all packages from a license and then deleting that license did the trick.

@jw thanks for clarifying! The pipelines in ProGet are not really meant to track status. The main reason for the build stages is to control automatic archival, issue creation, and notifications. For example, your stable releases might stay in a "Released" stage indefinitely. We also had (in the preview feature) threre build statues: Active, Archived, Released. We don't use Released currently, but definitely something we may bring back. You don't want to delete a Released build, but you would probably want to delete an Archived build. Anyway, I'd check out the pgutil builds promote command - that way you can keep your "archival rules" in ProGet.

Hi @jw, Thanks for sending this over. I created PG-2731 to track the fix. It should be out within the next two maintenance releases of ProGet. Thanks, Rich

Makes sense, thanks for the quick fix. Cheers

@jw we'll definitely keep this in mind, it doesn't look trivial based on our usage of that marked library Personally, I always try to keep the Diagnostic Center clean and empty, so when new issues show up I can easily spot and address them. Sifting through messages that are basically spam, without being able to filter or ignore them costs me more of my time that I would like to invest for monitoring. We do not recommend using the Diagnostic Center for proactive monitoring. It's only intended as a tool for troubleshooting things like connector or 500 errors that you / end-users encounter. There are a lot of non-problem errors and warnings logged that aren't worth time even looking at.

Maybe I'm getting old and 14px seemed to small In addition, we don't display a lot of textual information so the larger font size seemed to fill out the whitespace nicer, particularly in tables (which there are a lot). I was never really all that happy with how this filled out whitespace (from ProGet 2023): I'm not thrilled about ProGet 2024, but it felt like an improvement... and most importantly, "something different" than past few years: That said, for ProGet 2025 I'd love to do a much more notable style refresh (logos? etc?), perhaps even some navigation tweaks. So open to ideas there

I'm afraid this is a bit too granular for us now, but it's something we can consider re-evaluating down the line, especially as we will likely want to add specialize permissions for projects, policies, etc. We expect that will happen later in the year, after ProGet 2024's new features get more adoption. We'll see if anyone else requests package-level permissions, etc. Thanks for the feedback, let's see if there is more demand. As for the Advanced, I put a note in ProGet 2024's final touches to address that. Honestly I thought those were only on Debug builds only, but clearly not... thanks for reporting! Glad to hear it is just an UI issue, I was worried users could mess with metadata. Cheers

Looks like success! Thanks for addressing this so quickly.

Hi @jw , thanks for pointing this out! I added a note to review/investigate this in our run-up to finalizing ProGet 2024.

Hi @sebastian, Thanks for sharing your thoughts on this! Few things to point out... [1] The "Missing Package Problem" is not as bad in ProGet 2024, mostly because it will only apply when there's a license rule. In ProGet 2023, a "missing package" would happen even for vulnerabilities. [2] We're working on a new feature/module (tentatively called "Remote Metadata") that is intended to routinely cache/update meatdata from public repos like nuget.org, npmjs.org, etc. This feature enables two usecases: Routinely update "server-side metadata" like Deprecated, Unlisted on cached packages Fetch metadata for packages not in ProGet during build analysis It works somewhat independently, and basically it'll just show up on the Admin tabs as like "Remote Metadata" and you can configure providers, urls, etc. I hope to have a prototype in a couple weeks and will post some details on a new forum posts. As an FYI this is something we will limit in the Free/Basic editions and have full-featured in the ProGet Enterprise product. [3] "Package In ProGet" could be a policy rule to add after RMetadata feature, though it's probably not a big deal if ProGet can detect licenses thanks to RMetadata Best, Alex

Hi @jw, Thanks for letting us know about these. To answer your questions: This is an issue with the order of how we delete the projects and their child items. If you delete all the builds first, then the project can be deleted without issue. We will fix this as part of PG-2596 that will be released tomorrow in ProGet 2023.31. This is an oversight on our part. We will get delete buttons added to the Edit Project Settings and Edit Build Settings page also as part of PG-2596. Thanks, Rich

Thanks for adding it to the roadmap. From what I can see so far, there haven't been that many changes in the spec. For us mainly the author field changed. Right now there is no immediate need. It might arise in the future if improvements or fixes are only being made available in the CycloneDX 4.x tooling.

@stevedennis Famous last developer words: "Changing this one flag can't possibly break anything" Thank you for considering Cheers