I am trying to use $PSEval to do some simple boolean comparisons but I'm not having any luck. If I run a simple plan like

set $foo = true;
set $bar = true;
set $foobar = $PSEval($foo -and $bar);

then I get an execution error that I cannot assign a vector value to a scalar variable. If I change $foobar to a vector (@foobar) and print out its contents it's just an empty array. Currently I've created a powershell asset to do the operation and return the result but it is a bit verbose to write

  PSCall GLOBAL::BooleanOperation
(
    var1: $foo,
    var2: $bar,
    operator: and,
    returnValue => $foobar
);

so I was hoping there was a more "inline" way to accomplish this.

Product: BuildMaster
Version: 6.1.1

I just wanted to make a post to express that I think it is a shame to see the Schedule Triggers functionality be officially deprecated. Although it is clear that the feature is rooted in legacy code, what with its use of VariableDeclarations, it still provides unique functionality that cannot be easily replaced with webhooks or repository monitors. With the ability to trigger plans on a cron-like schedule, my team has been able to setup regularly recurring jobs to perform things such as nightly cleanups of the build servers and turning off virtual machines in the cloud when not in use.

I realize that just because a feature has become legacy doesn't mean my team can't use it and I also realize that my usecase for this feature is against its original purpose but I think with a bit of refactoring the idea of scheduled tasks would be a great stand alone feature for BuildMaster.

I also wanted to post this to see if there were any other users who were using this feature to run scheduled jobs.

Product: BuildMaster
Version: 6.1.0

I just recreated this. It appears that when only a single item is selected from the list the variable is created as a scalar(string) rather than a vector(list). This behavior is similar to Powershell's array unrolling so I don't know if this behavior is by design or if it is a bug. I was going to suggest a work around using the optional parameter of $IsVariableDefined to determine if the variable is currently a string or a list but it seems that function does not behave as expected as it returns true for me regardless of the variable's type. It wouldn't be pretty but I guess you could wrap your logic in a try/catch and attempt the logic again but treating the variable as scalar. Something like

try
{
    Log-Information The first item is @MyVariable[0];
}
catch
{
    Log-Debug Failure accessing MyVariable. Trying as a scalar.;
    Log-Information The first item is $MyVariable;
}

This was added to the Stop-Service operation back in April. It's simple enough to add it to the Start-Service operation. I've opened a pull request here.

The WriteAssemblyInfoVersions operation is part of Inedo's WindowsSDK extension. They have all of their extensions hosted open source on GitHub. You can see here that this operation is using the System.Version constructor. The documentation notes that a FormatException will be thrown if any component of the version does not parse to an integer so specifying '*' as the revision explains the error you are seeing.

As for how to get an incrementing revision number, usually this would be your $PackageNumber. By default if you don't specify a version to the operation it will fallback to $ReleaseNumber.$PackageNumber. For a brand new release with a single package this would look like 0.0.0.1 by default. However, if you are perhaps redeploying a package multiple times and need to distinguish between them you could use the $ExecutionId.

I just wanted to make a post to express my interest in BM-3239, that would allow users to dynamically specify a plan or module to invoke, and see if there is any additional interest from the community. I think with this operation we could get some really powerful flexibility in our workflows. This operation would let us create "wrappers" for our call statements that could do some pretty cool stuff. For example we could more easily aggregate the runtime of specific steps.

module InvokePlanTimerWrapper<$PlanName, %PlanArguments>
{
    set $StartTime = $PSEval(Get-Date);

    Invoke-Plan $PlanName
    (
        Name: $PlanName,
        Arguments: %PlanArguments
    );

    set $EndTime = $PSEval(Get-Date);

    set $script = >>
        `$start = [datetime]"$StartTime"
        `$end = [datetime]"$EndTime"
        (New-TimeSpan -Start `$start -End `$end).seconds
    >>;
   
    set $Diff = $PSEval($script);

    Log-Information Plan $PlanName took $Diff seconds to complete.;
}

We could also create a form of retry logic that doesn't rerun steps that already succeeded.

module InvokePlanReexecuteWrapper<$PlanName, %PlanArguments>
{

    set %ExecutedSteps = %PackageVariable(ExecutedSteps);
    set @ExecutedStepsForEnvironment = @MapItem(%ExecutedSteps, $EnvironmentName);

    if $IsReexecution && $ListIndexOf(@ExecutedStepsForEnvironment, $PlanName) == -1
    {
        Invoke-Plan $PlanName
        (
            Name: $PlanName,
            Arguments: %PlanArguments
        );
    
        set @ExecutedStepsForEnvironment = @ListInsert(@ExecutedStepsForEnvironment, $PlanName);
        set %ExecutedSteps = %MapRemove(%ExecutedSteps, $EnvironmentName);
        set %ExecutedSteps = %MapAdd(%ExecutedSteps, $EnvironmentName, @ExecutedStepsForEnvironment);
    
        Set-ReleaseVariable(
            Variable: ExecutedSteps,
            Value: %ExecutedSteps,
            Release: $ReleaseNumber,
            Package: $PackageNumber
        );
    }
}

Product: BuildMaster
Version: 6.0.10

Short answer, I don't think there is a straight forward way to accomplish what you want, currently. However, if you absolutely needed to implement something like this you could technically achieve it but there are few obstacles. Take this all with a grain of salt as I'm no BuildMaster expert.

First, the only two eventlistener types that support all event types are "Publish Event Details", like you saw, and also "Execute Command Line". Neither of these are particularly well suited for sending a simple email, for reasons below, so ideally you would create a custom eventlistener. However, I don't believe the InedoSDK has any interfaces for creating our own. So we have to choose between the two eventlistener types available.

If we go with the "Publish Event Details" listener, we would have to create some type of service to listen for the publish from BuildMaster. This service would consume the POST body and then send the email that you want.

The other option is to use the "Execute Command Line" listener. This option would require less overhead as you could just write a small batch script that sends an email. You can checkout this answer on StackOverflow for an example. However, we find there's an additional problem with using this approach. The "Execute Command Line" listener doesn't pass the event details to the executable. We have no way of telling what plan was modified.

Of course there's also a way around this if you have access to the database. In your script you could query the [BuildMaster].[dbo].[EventOccurences] table for the latest Plan Modified event (Event_Code=PLNMOD) and join that with the [BuildMaster].[dbo].[EventOccurenceDetails] table to see what plan was modified.

However with that all said and done, the specific event you want to listen to, Plan Modified, wouldn't actually work in v6.0.4 of BuildMaster, as it appears the [dbo].[Plans_UpdatePlan] stored procedure is not actually raising the Plan Modified event.

So in the end that was a pretty long winded way to say that I agree that there should be a "generic" send email event listener that can attach to any event and that I would +1 that as a feature request.

I agree. I think intuitively, the throw statement should allow a message to be specified but Write-Error works all the same I guess.

I think one approach you could take would be to utilize the Native API which, using your example, could be found at https://example.com/reference/api. You could call the Pipelines_GetPipelines endpoint, filter by "Active_Indicator" == true, then parse the "Pipeline_Configuration" xml for each pipeline looking for the "PlanName" attribute of the "Properties" element under the "Inedo.BuildMaster.Pipelines.PipelineStageTarget" elements. Here's a snippet of the "Pipeline_Configuration" I get back when I run this, to get a better idea.

<Inedo.BuildMaster.Pipelines.Pipeline Assembly="BuildMaster">
<Properties Name="All" Color="#499e8d" Description="The pipeline that deploys to all environments on all stacks.  " EnforceStageSequence="False">
	<Stages>
		<Inedo.BuildMaster.Pipelines.PipelineStage Assembly="BuildMaster">
			<Properties Name="Build" TargetExecutionMode="Parallel" AutoPromote="False">
				<Targets>
					<Inedo.BuildMaster.Pipelines.PipelineStageTarget Assembly="BuildMaster">
						<Properties PlanName="Main-Build" EnvironmentName="BuildFarm" DefaultServerContext="None">
							<ServerNames />
							<ServerRoleNames />
						</Properties>
					</Inedo.BuildMaster.Pipelines.PipelineStageTarget>
				</Targets>

From this you can see I have a Pipeline named "All" that has a stage named "Build" that calls the plan "Main-Build".

From the formal specification:

Log Statement
This statement has two elements:

Log Message – an expression
Log Level – an integer enum with valid values of (0=Debug, 10=Information, 20=Warning, 30=Error)
When this statement is encountered, the execution engine writes the specified message to the specified level. If Warning or Error is specified, the execution status will change appropriately (Error causes Failing, Warning causes Warning unless already Failing), but an error will not be raised.

I think you can accomplish what you want if you use Execute-Powershell instead of Log-Error.

Execute-Powershell >> Write-Error "Hello World">>;