Hi @scott-wright_8356, We haven't seen any other issues with this procedure in particular, but it's something we can consider to update. Have you considered that doing the commit with UPDLOCK and SERIALIZABLE could be causing issues with AlwaysOn and sycnchronsist commits going to the secondary? One thing we faced with ProGet 2023's new database model was handling different bugs in different version of SQL Server's analysis engine. Without this pessimistic lock, some versions of SQL Server 2019 will deadlock while updating totally unrelated indexed view. That said, you shouldn't need to use synchronous commits with ProGet in AlwaysOn. That's going to slow things down a lot to begin with, and that level of data-integrity is so important in ProGet. Thanks, Alana

Thank you atripp, confirmation of everything we thought was the problem and working on it now.

@atripp said in ProGet Diagnostic Center: Delete All Messagses: TRUNCATE LogMessages Thank you worked perfectly yes there were a lot of logs.

Hi @yogeshshines_9136 , This should be resolved by downloading the latest Inedo Hub from https://my.inedo.com/downloads Thanks, Alana

Hi @Justinvolved , I've never seen that error and it makes no sense. It's a random Windows COM error. It's not BuildMaster-specific, it's happening when invoking the MWA libraries to save IIS configuration. This would happen if you performed the identical action from with IIS Manager as well, wrote a PowerShell script, etc. I searched "a specified logon session does not exist. it may have already been terminated" and the advice is all over the place. It has something to do with permissions, I guess? Adding "IIS" adds more specific results, so maybe that will help. So my advice from here is to just search and try random things that people said work. Feel free to share what you found ! Best, Alana

Hi @atripp, So I associated the deployment targets with environments and that fixed both of my issues: $EnvironmentName is populated and now the environments are showing on that application screen: [image: 1707424775266-f2980f10-64c0-41a7-a082-7115d0d3b1ba-image.png] Thanks!

Thanks @dongjie789_8066; of course we can definitely consider creating a different API, but you are first non-Edge user to ask about it :) It's best to handle that through your My Inedo account with your work email, so we can work with your team/company about it

Hi @PhilipWhite , You're correct, this is a regression in the validation code... if (!value.All(c => (char.IsLetterOrDigit(c) && char.IsLower(c)) || c == '.' || c == '_' || c == '-' || c == '/')) return new ValidationResults(false, $"Docker Repository names may only contain lowercase letters, digits, periods, underscores, slashes, or dashes."); I guess we recently added char.IsLower because UpperCase characters caused all sorts of problems.... easy fix, and easy work around. Just enter blah in the Repository name field, Click Save Click "view all" Click on the Docker repository in that view, edit We'll get this fixed for teh next maintenance release via BM-3932 Cheers, Alana

@atripp Thanks, I installed 23.0.10 this morning and the git checkout task succeeds on the RedHat server. Next step is getting the docker build task to succeed. I may open a separate post for that.

It seems the 401/403 only happens for NPM/NuGet calls and not on the Web UI. If you'd like I can search for the corresponding log messages and get them to you for further troubleshooting. However, with the appropriate DB sizing the issue is mostly non-existent (once every few days) which is totally tolerable. Cheers Simon

@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