Topics created by v.makkenze_6348

@stevedennis I tried in a docker image but also could not reproduce it reading SBOM from the UI. We have a major release ahead perhaps i can try after the release, but failing builds scares people me included.

Hi @v-makkenze_6348 , We'll get this fixed via PG-3041 in the upcoming maintenance release; you can try out the prerelease container if you'd like (proget:25.0.4-ci.1), which is building now. -- Dean

Hi @v-makkenze_6348, Glad to hear it! Thanks, Rich

Hi @v-makkenze_6348 , This error was related to an error on our end - basically there was some bad data in the package that the InedoHub downloaded, and it caused the installer script to crash. We fixed the package on our end, so reinstalling normally should work now. Cheers, Steve

Hi @v-makkenze_6348, I was able to identify the issue, PG-2778, and will have this fixed in the next maintenance release of ProGet. Thanks, Rich

@apxltd At the moment we only have five I think. The adoption rate of it has been slow due to the SCA feature being very interesting but lacking the presentation of some valuable information, such as what this thread addresses. Once the adoption grows with increased information connectivity (builds with the associated packages for instance and this license component) we would likely have more than 300 or 400 build projects.

I did a "Pull to ProGet" and ran analyze again and now the warning is gone.

Hi @v-makkenze_6348 , Thanks for the report; please ignore this, it should not be logged in the Diagnostic Center. It's addressed via PG-2625 in ProGet 2024.1 Cheers, Alana

@stevedennis Thanks for the updated version - it works smoothly now.

Hi @v-makkenze_6348 , This error can happen if you made certain changes to IIS configuration; in this case, you changed the name of the ProGet site in IIS to something else. That is not supported, so you will get this error. In general, we recommend moving away from IIS; this is because Microsoft no longer recommends using IIS for modern applications (.NET). And there is weird behavior like this. They only recommend it as a proxy server and legacy application server (Classic ASP, .NET Framework, etc).

Hello @v-makkenze_6348 , We're aware of this issue, and it's related to NuGet packages with four-part versions that end in zero, and the way the package is handled behind the scenes. It's a fairly involved/complex issue that we need to fix in a major version -- and we've already done that, in ProGet 2024 :) We expect it to release soon. You'll need to delete the cached package then re-add it. We've tested this exact scenario w/ SCA Builds/Releases. Thanks Alana

@v-makkenze_6348 thanks for clarifying - that's not how we intended to use the feature, but hopefully the ProGet 2024 model will work better. In ProGet 2024, they are called Builds, and Builds have a Release Number. They are also auto-archived, and have a kind of Build Stage. Sorry but I don't yet have screenshots, but there is some documentation: https://docs.inedo.com/docs/proget-sca-builds

Thanks I made a backup and ran the script and it did clean up quite a few rows. I'll try upgrading to 2024 again next week after we released :)

@v-makkenze_6348 Thanks, we'll add this to our "final touches" in PG2024 :)

Hi @v-makkenze_6348, It's hard to say for sure, but there's clearly some kind of database timeout problem here when running Projects_GetReleaseAnalyzerData . I suppose you could try running that directly, and see if it takes a long time? I suspect the issue is that you have too many active releases. This is a major issue with ProGet 2023's feature -- it was designed with the assumption that users would archive releases, but we've seen thousands in the field. If you have a lot of active releases, this cause some big performance issues. ProGet 2024 auto-archives builds (the new word for releases). Cheers, Alana

Hi, I checked again and the number of packages is correct when the build succeeds. Had to run the build 9 times before I had a build that did not give a timeout. Before i counted the number of components in the SBOM but the app itself is also a component and i have two SBOM's so therefore i was missing two packages. I get the feeling that during the failing builds the SBOM is uploaded but not completely processed. So the next build its processed and thats when i see three SBOM's or four if the build succeeds. Still no clue why this is the only build that has these failures, its not our biggest or most complex product. We don't have many builds that contain both npm and nuget packages but there are others. All builds are run at least once a week so the others with two pgscans are ok.

Hi @v-makkenze_6348, thanks for the report, I was able to reproduce it with that particular package. We plan to resolve this via PG-2587 in the next maintenance release scheduled for next Friday.

Hi @v-makkenze_6348, We've rewritten this to not use MERGE, which should help; we plan to ship PG-2583 in the upcoming maintenance release on Mar 1. Cheers, Steve

Hi @v-makkenze_6348, This fix has been released in pgscan 1.5.7. Please let us know if you have any questions! Thanks, Rich

Thanks, I updated and feed cleanup is back to seconds instead of hours