Topics created by paul_6112

@rhessinger said in BuildMaster v2023 PSCall: Hi @paul_6112, What version of the Scripting extension do you have installed? This bug should be fixed in v2.4.0 of the Scripting extension. If it is not currently version 2.4.0, can you try updating that extension and see if that fixes the issue? Thanks, Rich Thanks Rich, This does appear to work okay on BuildMaster 2023.5 and Scripting 2.4.0

Hi @paul_6112 , That's really peculiar; what must be happening is that PowerShell is returning multiple results, so the variable is automatically being being created as a list: https://github.com/Inedo/inedox-scripting/blob/master/Scripting/InedoExtension/Functions/PsEvalVariableFunction.cs#L52 Digging further, it's like related to some issue with value detection/conversion: https://github.com/Inedo/inedox-scripting/blob/master/Scripting/InedoExtension/PowerShell/PSUtil.cs#L205 Unfortunately it's a bit of rabbit hole from here; it's just as likely a bug in .NET6 powershell libraries as it is our code. But hopefully you can play around and find a work around? I'm at a loss, and we're pretty heads-down in ProGet 2024 planning at the moment, so hard to find the likely half-a-day to explore this further. I'll add this to our BuildMaster 2024 roadmap, but if anyone else experiences this (or we get a ticket) we'll investigate it further. Cheers, Alana

Hi @paul_6112 thanks for the report -- this is a known issue/regression in our internal UI library with focus- it only impacts a very few number of pages, but it's on our list to eventually address

Hi Rich, Brilliant, thank you for the update. Regards, Paul

Hi Rich, Super, thank you. Regards, Paul

Hi @paul_6112 , we could definitely be more consistent here. The listing is generally called "Deployments & Executions" , which we shorten to "Deploys". I'll make a note in our roadmap to review this!

Hi Alana, Well.... technically none of your software is supported since you are a free user https://inedo.com/buildmaster/pricing I'm currently getting my money's worth on this forum after an upgrade to v2023 Thanks, Paul

Hi @paul_6112 , Thanks for letting us know that this is still an issue. I created a ticket, BM-3913, to track this fix. Thanks, Rich

Hi @paul_6112 , Thanks for letting us know that this is still an issue. I created a ticket, BM-3914, to track this fix. Thanks, Rich

Hi @stevedennis , Perfect, thank you. Regards, Paul

Hi @paul_6112 , The general philosophy that BuildMaster was designed around is this: A "Release" is an intended set of changes to production A "Build" is an attempt at implementing those changes When a "Build" makes it to production (i.e. the final stage in the pipeline), then the changes were applied to production, thus the "Release" has occurred If you want to change production again, then you create a new "Release" This means that, after build of 1.1 is successfully deployed to production (and no rollbacks are needed, etc.), it cannot be released again. You'd need to do 1.2, or so on. However, in practice users want to deploy 1.1 build 1234 to production, and then 1.1 build 5678 to production. So with this, we have a few options: Create the releases 1.1.1234 and 1.1.5678, and then have build 1 (sounds like you're doing this) Create Release 1.1.0 Build 1234, Release 1.1.1 Build 5678, and use a Release Name of 1.1 (this overrides the display in nearly all places) Edit the pipeline, and uncheck "Mark the release and build as deployed once it reaches the final stage."; this will give you more control over changing release status Don't use releases at all (set Release Usage to None on advanced settings), and have the build number be 1.1.1234, 1.1.5678 Definitely open to some other ideas as well. A few users have had to "workaround" this design philsophy, and we'd rather just support it!

@paul_6112 well, as it turns out... this was actually trivial to fix It will make it in 7.0.19, scheduled for Feb-25th

Hi Rich, Just installed 7.0.14; thanks for the fix Regards, Paul

Hi @rhessinger, Thanks for the fix in 7.0.14 Loving your work once again !! Regards, Paul

Hi @gdivis, I've just installed v7.0.14 and the behaviour seems improved. On the original thread track; Using hub v1.3.7 the upgrade from v7.0.13 to v7.0.14 went through without getting stuck. After upgrade, both Test and Production web pages were able to load in less than 2 minutes. There is CPU spiking; but seems more spread out and the max memory is now two thirds of what it was; however within 6 minutes of startup its back around the 160MB - 350MB (it was idling at 160MB before upgrade) which is a definite improvement. Thanks, Paul

Hi @paul-reeves_6112, No problem! Always happy to help. Thanks, Rich

Hi @atripp , Great, thank you ! They are also removed from the Release Overview page. Thanks, Paul

Hi @paul-reeves_6112, That's ok. It went through our internal testing and everything looked good so we pushed it to production with the last release. Thanks for verifying this for us! Thanks, Rich

Hi @paul-reeves_6112 , Of course, it should totally work in the usecase you described, I just wanted to explain how it got missed during testing :) In general, we recommend not including configuration files that contain environment-specific configuration in artifacts to begin with, or at least using include/exclude filters on the Deploy Artifact operation. Then, deploying using the configuration files feature. But that's just general advice of course. However, your use case sounds a little different, in that you want the configuration file deployed, but only the first time? I don't have a great solution to that, but the main downside I see is that engineers who manage/edit the configuration file (add values, etc), may be surprised when it's "not deploying" like they expect it to. Config files can be tricky to balance as you probably already know :) Cheers, Alana

Hi @atripp , This is great, thank you :-) Regards, Paul