I have a fairly simple Psake build script (default.ps1) that calls Invoke-Psake from within one of the tasks. Something like this:
(default.ps1)
. .\utilities.ps1
properties {
...define some properties
}
task default -depends Step1
task Step1 {
Invoke-Psake script2.ps1
}
The second build script has a task and does its thing.
(script2.ps1)
. .\utilities.ps1
properties {
...define properties
}
task default -depends script2.CreateSchema
task script2.CreateSchema {
Invoke-Sqlcmd ....(parameters)
}
The tasks work fine; the Invoke-Sqlcmd call works.
The problem I'm facing is if for some reason the script2.CreateSchema task fails Psake still reports that the build succeeds. The task failure in the child script is not bubbling up to the parent script such that Psake fails the build.
Anyone run into this? Is this maybe a problem with the new nested build feature of Psake?
Psake v4.0
Powershell v2.0
This is apparently a problem in Psake as confirmed by the feature author. I cross-posted on the Psake Users Google group.
Related
I have started using a monitoring system called Cronitor that wraps scheduled task executions in their EXE.
Cronitor.exe exec (UID for monitor) "Path to script/executable".
Adding to that, I am working on synchronizing some of our scheduled tasks that are dependent on each other.
The problem I have is that because the executable wraps scripts/programs/tasks, the error code returned to Windows task scheduler is always 0 because it's not passed in their exe.
My work around is to layer powershell scripts (which I am not super proficient in yet).
So Action 1 calls "StartAction.ps1"
Inside that ps1 script,
Start-Process "Path to cronitor" -ArgumentList "Crontior arguments and path to ps1 that initiates exe for action 1" -Wait
Start-Process "Path to cronitor" -ArgumentList "Crontior arguments and path to ps1 that initiates exe for action 2"
The issue I am running into is the same for trying to stop the scheduled task if the process fails in action 1. I need to pass the error code (1) up through a pipeline to the initiating script so it knows to stop.
Is that even possible, or are there other solutions I am missing?
In the Azure DevOps release pipeline I run Inline Script as part of the Post Deployment Action of Azure App Service Deploy task (Task version 4.*).
The inline script looks like this:
powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -File UpdateCSP.ps1 -ApiUrl "$(API_URL) $(API_TESTING_URL)"
powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -File GenerateVarsJs.ps1 -ApiUrl "$(API_URL)" -IdamAuthServerUrl "$(AUTH_SERVER)" -IdamClientId "$(CLIENT_ID)" -TestApiUrl "$(API_TESTING_URL)"
One of the scripts was hard terminated (by invoking Throw "some error text") command. The error was written into the task output but the task itself succeeded.
Hard terminated powershell script returns error code 1. Therefore my expectation was that script failure would also fail the task.
I would need the task to fail in case of script failure (nobody is checking the output of succeeded task). How this could be done?
I carried out a simple test. And it worked fine.
I have a simple command throw "This is an error. in the .ps1 file. I call the script in the Post Deployment Action of Azure App Service Deploy task:
The task failed as expected:
However, You can have a try using logging commands #vso[task.complete result=Failed;]Failed in the .ps1 file to manually fail the task. See below:
Throw "some error text"
Write-Host "##vso[task.complete result=Failed;]Failed"
Or You can try using [Environment]::Exit($exitCode) after the Throw command in your .ps1 file.
Throw "some error text"
[Environment]::Exit(1)
Unable to run TestComplete scripts through powershell script using TFS Release Management task "Powershell on Target Machines".
The task is initiated in Release management and never completes. Are there any special arguments to be passed to powershell script in order to execute the test script interactively.
Manually running the powershell script on the release agent machine executes without any issue.
The Script argument are the arguments required by the script, if any.
-NoProfile is an argument which powershell.exe accepts, try removing that.
In a PowerShell Workflow activity, I can call a native PowerShell script using InlineScript:
workflow test
{
InlineScript
{
.\script.ps1
}
}
But in Azure Automation, the dot-path (at least in my tests) was returning c:\windows\system32, and the script-as-runbook in Azure Automation did not exist there (or rather, it failed to execute because it could not find the script).
Is it possible to execute a native PS runbook stored in AAuto like this?
If so, how do I specify the path to the file?
Is this a bug/oversight in Azure Automation's parsing/compilation process of Workflow runbooks & InlineScript activities, preventing the dependent runbook from being copied to the worker?
I did a little hunting, and found that when native PS runbooks are executed:
They are first inspected for any other runbook references.
As part of the deployment to the worker for execution, a randomly-named folder is created under C:\Temp\
Referenced runbooks are eventually copied to this folder.
If runbooks are NOT found to be referenced, they are NOT copied to the temp directory.
The root runbook does not appear to be copied to the folder.
The dynamically-named folder is NOT created (under c:\Temp) when executing a Workflow runbook.
As part of the standard Workflow compilation, InlineScript activities have their contents copied to the autogenerated xaml. I'm uncertain about a linked file, though based on behavior that looks to be a runtime concern. My guess is that compilation happens each time a workflow is executed (hence the delayed start), and takes place on the worker, utilizing the standard PS workflow compilation just like local would.
I cannot (easily) convert this script to a workflow, and it is used from within other workflow activities. Right now the only way I can make this 'work' is to copy & paste the script into the first InlineScript within a workflow that requires it, which is obviously tedious & annoying from a maintenance perspective.
Presumably, as a workaround, I could use a Hybrid Worker, but that comes with a host of other issues, like ensuring the child runbooks are published there & having to maintain them separately, or AAuto not automatically pushing custom modules from the Automation Account to the worker (though this is planned), etc.
Please see https://azure.microsoft.com/en-us/blog/announcing-powershell-script-support-azure-automation-2/:
Right now, you can only invoke inline PowerShell runbooks from PowerShell runbooks, and PowerShell Workflow or Graph runbooks from PowerShell Workflow or Graph runbooks. This may change in the future.
It hasn't changed yet :)
We are using TeamCity Enterprise 8.0.5.
I have a TeamCity build step which runs a PowerShell (.ps1) script, which looks like this:
try
{
# Break something
$a = 1 / 0
}
catch
{
Exit 1
}
Despite this, in the build log, the step succeeds and exits with code 0.
[10:02:18][Step 2/3] Process exited with code 0
I want the step to fail if there are any failures in the script. How can I make this happen?
I have just discovered this post:
PowerShell runner - script fails but the build succeeds - 'Process exited with code 0'
There is a bug in TeamCity which means that non-zero PowerShell return codes are not picked up.
The solution suggested is to create a build failure condition on detection of certain text output into the build log.
However, my solution involved something different.
In the catch block you only have to use the Write-Error cmdlet:
catch
{
Write-Error -Exception $_.Exception
}
Then you must ensure that two things are set correctly in TeamCity:
Firstly, the build step Error Output should be set to error, and not warning:
Secondly, in the build failure conditions screen, make sure an error message is logged by build runner is checked:
Suppose you are using psake and your goal is to fail your build if your build script fails. The script which imports the psake module and invokes the build script does not fail, so TeamCity takes it as a successful build.
Add this code into your first script to fail your build if the second script fails.
Import-Module .\psake\psake.psm1
Invoke-Psake .\build-steps.ps1 #args
if($psake.build_success -eq $false){
Write-Host "There was an error running psake script"
exit 1
}
Remove-Module psake
Do not remove the module before the if statement.