@atripp said in [BM] Proget::scan usage - I am looking for example: I missed package-lock.json. This is working fine now. Thank you { ProGet::Scan ( To: global::proget-2023, Project: package-lock.json, ScanType: Npm ); } Best Regards

@atripp I am using the docker version of OTTER. About the Get-DsCResource, it is working fine on the server. I will see if can make a test case. Best reagrds PhilippeC.

@atripp I can wait, thank you Best Regards

Hi @atripp Thanks for the update. Microsoft is killing me Best Regards PhilippeC.

Thanks for the report and work-around @Jon , we'll investigate this as part of the Otter 2024 roadmap.

@Jon I answered this in another thread, but The error for "/api/releases" should be logged under Admin > Diagnostic Center; it's likely related to an unexpected/missing data in the application; you can narrow it down by specifying application id or something If you can find what the error is, we can work to id/fix it!

Hi @Jon, The Release and Build API Documentation is outdated and needs a lot of work. We are aware of the low-quality documentation, and this is on our list to rewrite. To address your issues. [1] The error for "/api/releases" should be logged under Admin > Diagnostic Center; it's likely related to an unexpected/missing data in the application; you can narrow it down by specifying application id or something [2] You'll need to specify application/json as the content type when posting JSON documents; otherwise the request will be read as application/x-www-form-urlencoded values or querystring parameters. [3] The pipeline name is incorrect, it should simply be Release (for an application pipeline) or global::MyGlobalPipeline for global pipelines. Thanks, Alana

Hi @Jon , Thanks for the note; this behavior is intended, and was decided after many years of supporting products in the field. The service is configured to automatically restart after a crash, and a database error will crash the service. This is easiest to manage, since most database connection errors (even permissions-based ones) are are temporary in nature, so this behavior means the problem will be automatically resolved. Best, Alana

Hi @Jon , Unfortunately it's "not that simple", and this will require a bit of troubleshooting to figure out what the issue is, precisely. There are a lot of areas where this could occur, and we can't add a generalized "job killer" until we understand what the issue is. You'll have to dig in behind the scenes (Admin > Executions) and identify exactly where things are freezing. The last log message will indicate that. Try to find as many examples as possible. Keep in mind that Otter is not not really "connected" to a server, and a server does not (and cannot) "call home". Instead, Operations (i.e. OtterScript) opens a connection to a server, sends a command, then disconnects. All network errors we've ever seen in this process will yield a crash. However, unless explicitly specified, a command will not timeout. So this means if you run a PowerShell script that basically just says "sleep indefinitely", then the Execution will never complete. Obviously no one would write that script, but some PowerShell scripts have a consequence of that. No built in Operation should ever cause that to happen, which is why we need to know precisely where this is happening. Best, Alana

Hi @Jon Based on my experience, you need to add a configuration to each role like an ensure-file a dummy file to force the drift detection and the remediation for each role. Having a role without a configuration leave the status in unknown state. Hope this help Best regards PhilippeC.

Hi @dario-wigger_0347, The configuration looks okay, and is basically what we have documented. So I think it ought to work... From here, I would start by monitoring the HTTP traffic between Maven and ProGet. You can use a tool like Fiddler Classic on Windows or Wireshark. What you should see is: Maven issues a request, and ProGet returns a 401 with WWW-Authenticate: Basic header Maven reissues the request, sending a Authorization: Basic XXXXXXX The XXXXX will be Base64 encoded api:your-api-key. If you don't see that, then something else is wrong. I would post it and maybe we can help. You can also try downloading maven artifacts from an "Incognito" window. Your browser should also prompt you for a username/password, and then you can enter api and your api key. Thanks, Alana

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

For the modules, 2 ways Create a second role which depend on the previous one and use Ensure-psmodule function to add the required module You don t need the set psgallery to be trusted if you use the Force in the Ensure-psmodule Cf https://docs.inedo.com/docs/otter-reference-operations-powershell-ensure-powershell-module

Hi @Justinvolved, The easiest way to setup a test environment for this would be to setup an instance of Otter (free edition is fine). Then once you have checked out https://github.com/Inedo/inedox-windows and made your changes, you can package the extension using the Inedo Extension Packager. This is available as a .NET tool. You can then navigate to the extensions page and upload the extension file to Otter. You may need to modify the AssemblyVersion in AssemblyInfo.cs to a version newer than the installed version to get it to pick it up as the lastest. Alternatively, you can copy that extension file to the Extensions.ExtensionsPath and restart Otter to have it pick up as well. The command I typically run to package the extension is: inedoxpack pack InedoExtension Windows.upack -o --build=Debug I run that command from the the solution file's directory. Hope this helps! If you have any questions, please let me know. Thanks, Rich

Hi @Justinvolved, Would you be able to send us the output of Get-Module -ListAvailable on PowerShell 5.1? I would like to take a look and see if there is anything causing a parsing error in Otter. If it is not safe to post here, you can email it to support@inedo.com and prefix the subject with [QA-1405] and then comment back here when you have sent it. Thanks, Rich

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 Alana, thanks for the information!

Hi @richard-allen_8963 , I'm afraid I'm really not sure how different versions the NuGet client tools behave in different scenarios... just really how ProGet works in implementing the Vulnerabilities information on the NuGet API. This API is used by Visual Studio, and in our testing, they show up as we expected -- so if you're not seeing the desired behavior, that's where you'd want to look. Using something like Fiddler, you can see what's being called. I do know there is an older, NuGet.org-only API that the tools may be calling. But we only implement the one I mentioned above. Best, Alana

Hi @andy222 , The Git issue should be resolved; that was related to some authentication issues with newer versions of GitHub Enterprise. It broke a lot of tools across the board, apparently. Anyway, I see it just got fixed today. Check out BuildMaster 2023.10-rc.5 if you can How about pushing a NuGet package instead? That's a much more common scenario (folks migrating from Octopus), and it's one we're going to add some good first-class support for in BuildMaster 2024. Thanks, Alex

Hello @atripp You save my day. Increasing the timeout resolve the pb. Thank you