Topics created by caterina

Hi @caterina, Good catch! We'll get that fix merged in. Thanks, Rich

Hi @stevedennis, thank you. It looks like you guys created a seperate repo for ConsoleMan: https://github.com/Inedo/ConsoleMan I guess this one creates the NuGetPackage? Thanks, Caterina

Hi @caterina , I agree and there doesn't seem to be any good usecases or official guidance from npm tags command, but we do not recommend using them: https://blog.inedo.com/npm/smarter-npm-versioning-with-semver/ From the api/technical standpoint, npm tags are a little weird -- a package themselves doesn't contain tags. Instead, the registry has a key/value tag store. By convention, the store has keys like latest and values like 4.8.1, but it seems to allow anything? At least from data we've seen on npmjs.org In any case, the npm client seems to set a latest tag, so we'll just support that use case then. FYI here is the logic/code I added: var tags = await this.GetPackageTagsAsync(purl.Name, false, cancellationToken: cancellationToken); if (tags.TryGetValue("latest", out var latestVersion) && latestVersion == PackageVersion<SemanticVersion2>.Parse(purl.Version)) await DB.Npm_SetTagVersionAsync(toFeed.FeedId, purl.Name.Id, "latest", purl.Version, DateTime.UtcNow); It sets the latest tag on the other feed if the current feed's latest tag points to the package you are promoting. Thanks, Alana

Hi @rhessinger, thank you for pointing out the feed features. License detection was not enabled in the feed I used for testing. After activating the feature the package is being reanalyzed correctly and the global policy is being used. Thanks Caterina

Hi @caterina, Thanks for bringing this to our attention. I have created a ticket, PG-2990, to track the fix and it should be released in the next maintenance release on June 13th. Thanks, Rich

Hi @caterina , In ProGet 2024+, the Project Analyzer will give some kind of warning/error and builds 1001+ will be in an "inconclusive" state instead of "Compliant", "Warn", or "Noncompliant" That said, ProGet 2024+ does include capabilities to auto-archive builds through use of status/pipelines, so that might be worth investigating. Thanks, Steve

Hi @caterina, I'm sorry about this. There looks like there was a conflict with another notifier change. I have created a new ticket, PG-2933, to fix this and it will be released in the next maintenance release. Thanks, Dan

Hi @caterina , This will be fixed in the next maintenance release via PG-2829. I just checked in the change. I made a mistake when making the original change, and used the ProjectBuildId instead of the ProjectId when validating the if other builds exists. So it works if the Ids match perfectly (like when I tested it). Note this only impacts the UI, and we don't really expect users to create builds via the UI. Thanks, Alana

Hi @atripp, thank you for the clarification. I can confirm this behavior. Thank you very much, Caterina

Hi @caterina, No problem, thanks for getting back to us. We have an upcoming release of pgutil that will include this flag. We also have improved this command a bit by allowing you to use the working directory which will search for the right files instead of --input having to specify the path to the file (although you still can). It will now also automatically audit the scan directly after, you can use --noaudit to skip the audit. We should have those updates pushed this week. Thanks, Rich

Hi @caterina, We're a bit concerned that this is too specific for your usecase, and we're really struggling documenting it. Instead of doing this, we're thinking it might just make more sense to run (Get-Item 'C:\path\to\file.exe').VersionInfo using PowerShell and export these into variables instead. For Example: $versionInfo = (Get-Item 'C:\path\to\file.exe').VersionInfo $version = if($versionInfo.FileVersion) { $versionInfo.FileVersion} else { $versionInfo.ProductVersion } $productName = $versionInfo.ProductName pgutil builds scan --input=myApplication.csproj --project-name$productName" --version=$version Thanks, Dan

Hi @gdivis thank you for your response. This is what I was looking for! Thanks, Caterina

Hi @rhessinger, thank you very much! We will just wait for the next release and I will come back to you if we encounter further problems. Thanks, Caterina

Hi @caterina , Thanks for checking; I was able to reproduce this; it seems to be a regression.... we'll get it fixed via PG-2795 in next week's maintenance release. Thanks for letting us know. Thanks, Alana

Hi @atripp thank you very much, downloading the latest version solved my issue. Best, Caterina

Hi @atripp, thank you very much for clarifying this. We are not able to update to ProGet 2024 yet, so I will just resolve this issue manually for our projects. Thanks, Caterina

Hi @gdivis, thank you very much for your response! We are really looking forward to the finalized version :) Thanks, Caterina

Hi @gdivis, thank you for your response. I think it is a little bit confusing in general. Just for clarification: We are not using any symbol packages at all (neither .symbols.nupgk nor .snupkg). We are only embedding PDBs right into our .nupgk files. But it would be nice to strip the PDBs on package download. We can achieve this on ProGet by activating the symbol server for the legacy format. I was just confused on why I have to use "legacy" for this approach since it is also standard to embedd the PDBs instead of using symbol packages. I guess normally it won't be necessary to enable a symbol server if you are using embedded PDBs. But we want to see the symbol information for our packages and we want to be able to strip the PDBs on download. It seems to be more of a hack to use the legacy symbol server for this but we achieve our goals doing so. No need to file a bug for this. Thank you, Caterina

Hi @rhessinger Thanks, but I don't think we will need a pre-release. The remaining problem is basically a convenience issue (getting from the report to the package's info page with one click). Everything else seems to work as expected with the latest pgscan version.

Hi @caterina, Here is the final solution: When using the auto type and scanning for NuGet and npm dependencies: The default configuration should be to omit dev dependencies and scan the node_modules directory When using the npm type and a package-lock.json file is specified The default is to only scan the specified package-lock.json file and omit dev dependencies When using the npm type and a package-lock.json file is not specified The default configuration should be to omit dev dependencies and scan the node_modules directory Each of these options would have an optional parameter to include the dev dependencies (--include-dev) Each of these options would have an optional parameter to ignore pacakge-lock.json files found under node_modules (--package-lock-only ) This has been implemented in pgscan 1.5.6 which I will be pushing shortly, and these options will be added to BuildMaster 2023.2. Thanks, Rich