Topics created by Justinvolved

Hi @Justinvolved , This is not uncommon with PowerShell; in general the processes will be closed, but there are enough scenarios with long-running/hanging PowerShell scripts where those processes will report termination but the process will not be terminated. So they can stick around I'd recommend using the Inedo Agent instead, even if it's on the same sever. That gives better process isolation compared to the local agent, and you shouldn't see this behavior for too long. The local agent runs in-process. Cheers, 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

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, 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 @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 , Application Pools seem to run under a special user account (not NETWORK SERVICE, but like IIS\AppPoolName), so you need to give that user access. In any case, make sure to restart the app pool/IIS, otherwise the permissions may not cascade? It can be a bit tricky unfortunately. Cheers, Alana

Hi @Justinvolved , The biggest consideration for using "separate applications" is versioning and independent deployment. For example, our extensions are all separate applications, but nearly all of them are bundled with product release. For example, see the the the %ExtensionVersions variable on a recent build of BuildMaster. The Git::Checkout-Code will default to $Commit and $Repository variable functions for the BranchOrCommit and From arguments; those variable functions contain the values that you selected when creating a build. So you can just specify different values as needed. See: https://docs.inedo.com/docs/buildmaster-git-source-control#build-scripts-operations Likewise, the Deploy-Artifact operation defaults to $ApplicationName, $BuildNumber, Default, etc, so you can specify values as needed. But like all things in software, no matter what approach you use, it will probably end up being "wrong" and you'll want to redo it later. So just plan on doing a "v2" down the line :) Alana

Hi @Justinvolved , Ah yes, getting all this modeling done sensibly is a challenge, and documenting it is a whole new pain The main issue we're facing is that you can't create a Site in IIS without a binding; the API will simply reject it and error. This means that if you use IIS::Ensure-Site to create a site, but don't specify a binding, it will error. However IIS::Ensure-Site can update a site no problem. This is why we originally created the Bindings property. However, it's a but challenging to use, and exhibits the behavior you describe: it "ensures" that list matches whatever is in the Site. Our current way of thinking is this: IIS::Ensure-Site MySite ( AppPool: MyPool, Path: C:\Websites\MySite, BindingProtocol: http, BindingHostName: app.local, BindingPort: 80 ); IIS::Ensure-SiteBinding ( Site: MySite, Protocol: https, ... ssl properties ... ); Our "new" way of thinking is that it might make sense to allow IIS::Ensure-Site to have two sets of binding properties. IIS::Ensure-Site MySite ( AppPool: MyPool, Path: C:\Websites\MySite, HttpHostName: app.local, HttpBindingPort: 80, HttpsBindingPort: 443, HttpsCertificateOrWhatever... ); This seems to align with how most people want to set up a site in IIS (i.e. two bindings). Definitely open to your feedback Cheers, Alana

Hi @Justinvolved , You should be able to see some kind of error message on Windows Event Logs, but my guess is that the account doesn't have access to the BuildMaster SQL Server database .. you'll need to grant that. Cheers, Alana

Hey Steve, Seems something was stuck somewhere, I re-created the resource and reset the service and now I can connect. Cheers, Justin

Hi @Justinvolved, You can create Global pipelines and scripts, which you can then use across applications. You can see this in action here, in one of our extensions: https://buildmaster.inedo.com/applications/18/scripts/all?global=False Click on "Global (shared)" to see all the scripts. Same is on the Pipeliens page. Cheers, Alana

Hi @Justinvolved , Oooh - I thought we removed those flags/notices from BuildMaster 2022 Looks like we only removed the code that clears them, and almost all of the code that sets them (with the exception of the CEIP page). Anyway, I've vanquished the code for good via BM-3839. In the mean time, please run sql this command to clear the notices: DELETE [Configuration] WHERE [Key_Name] IN ('Service.DelayExecutionsWhenRestartRequested','Service.RestartRequested', 'Web.RestartRequested') Cheers, Alana

Hi @Justinvolved , That error message is coming from here: https://github.com/Inedo/inedox-git/blob/master/Git/Git.InedoExtension/Operations/CanonicalGitOperation.cs#L73 Basically, it means that value you've specified for From is not a known Secure Resource. It's not a common error, and is likely the result of deleting/re-adding something. I would remove the From argument from your OtterScript altogether (just leave it as Git::Checkout-Code;). I don't think you need it. Your build should already associated with a repository, branch, and commit. Cheers, Alana

Hi @atripp Thanks, that looks easy enough, So I will get to it :-) Justin

Hi @atripp, Thanks that helped me solve it pretty quickly, just a typo somewhere in the script variables. Very happy to have learned about the verbose setting :-) Justin

Hi @Justinvolved , Hundreds of configuration files in one application -- definitely too much. I'd probably seek a different solution if that's the case. But having one or a few per application is okay. There is an Http-Post Operation that you can probably use to make API calls. Conceptually it's similar to the PowerShell Invoke-WebRequest method. I'm not sure what the configuration file would look like (array? map variable?), but there's also a variable function, ($Filecontents()), that could read a file, and an $Eval() function that can can convert text into variables. That said... it might be a bit challenging to do all this in OtterScript. It's not really designed for this. You may be better off writing a global PowerShell script that can process input from a configuration file that you deploy to the working directory. That would also be easier to test as well. Cheers, Alana

Hey Greg, Thanks, changing to C:\Temp solved the issue indeed, so I guess the path was too long. I'm experimenting with the Inedo Agent to make sure I can scale up and not have everything tied to Localhost, seems that was a good call given these subtle differences :-) Cheers, Justin

Thanks for clarifying @Justinvolved I was able to reproduce this issue, looks like it was a regression with "releaseless builds". Easy fix... it'll be in the next maintenance release as BM-3808. The release is scheduled for this Friday :) Cheers

Hi @Justinvolved , Ah, thanks for clarifying that! Yes... they should be Testing to follow everything else. Pipeline templates are a brand-new feature :) This was a trivial change, and will be updated in next version as BM-3805 Cheers, Alana

Hi @Justinvolved, That message that says "currently contains 0 items" is just telling you that the folder that the artifact is deploying to contains 0 files. After that, it will deploy the artifact files. If you enable verbose logging (setting Verbose: true), you will see all the files transferred from the artifact to the working directory. Thanks, Rich