I have the following scenario.
I have 5 build steps in teamcity for a project . I want 5th step to be executed only if the branch is master. The team city process should exit without executing 5th step if the branch is not master. Is it something I can achieve through powershell?
I think the only way to do this is to have a powershell step as step 5 which simply checks the current branch (%teamcity.build.branch%) and errors if its not master, then have the step that you want to run which is currently step 5 as step 6.
Team city doesn't always like to fail if the powershell steps fail, especially in versions before the current one.
To get around this we use the as the source script, but it assumes the script you want to run is in source control:
& "%teamcity.build.checkoutDir%\Path\To\PowershellScript.ps1" "%teamcity.build.checkoutDir%"
Write-Host "The result was of the previous script was " $LASTEXITCODE
Exit $LASTEXITCODE
The linked answer contains more options depending on which version you are using, so I'll assume you can find exactly how to get a failure to stop the build there.
Related
I'm completely new to Bamboo, so thank you in advance for the help.
I'm trying to create a Bamboo Run that zips files from a git repo and uploads it to Artifactory. Currently my build contains 2 tasks - source code checkout and a simple powershell script. The first time I run it it builds perfectly fine, but without any modifications any consecutive runs fail.
The error I'm getting in the log is the following:
Failing task since return code of [powershell -ExecutionPolicy bypass -Command /bin/sh /opt/bamboo/agent/temp/OR-J8U-JOB1-4-ScriptBuildTask-539645121146088515.ps1] was -1 while expected 0
Replacing the powershell script with empty space does not resolve the issue - only removing the script completely allows the build to succeed, but I cannot reinsert a new script or it will fail. I read other online questions suggesting that I "merge the user-level PATH environment information in to the system-level PATH" but I cannot find the user-level environment information, my environmental variables section is completely empty.
Like Vlad, I found that it was more efficient to implement my powershell script with batch.
I have a PowerShell task in my definition that calls another script file on its own which takes care of running several things on my build agent (starts several different processes) - emulators, node.js applications, etc.
Everything is fine up until the moment this step is done and the run continues. All of the above mentioned stuff gets closed with most of the underlying processes killed, thus, any further execution (e.g. tests run) is doomed to fail.
My assumption is that these processes are somehow dependent on the outermost (temporary) script that VSTS generates to process the step.
I tried with the -NoExit switch specified in the arguments list of my script, but to no avail. I've also read somewhere a suggestion to set this by default with a registry key for powershell.exe - still nothing.
The very same workflow was okay in Jenkins. How can I fix this?
These are the tasks I have:
The last PowerShell task calls a specified PowerShell file which calls several others on its own. They ensure some local dependencies and processes needed to start executing the tests, e.g. a running Node.js application (started in a separate console for example and running fine).
When the task is done and it is successful, the last one with the tests would fail because the Node.js application has been shut down as well as anything else that was started within the previous step. It just stops everything. That's why I'm currently running the tests within the same task itself until I find out how to overcome this behavior.
I am not sure how you call the dependencies and applications in your PowerShell script. But I tried with the following command in PowerShell script task to run a Node.js application:
invoke-expression 'cmd /c start powershell -Command {node main.js}'
The application keeps running after the PowerShell script task is passed and finished which should meet your requirement. Refer to this question for details: PowerShell launch script in new instance.
But you need to remember to close the process after the test is finished.
There is the Continue on error option (Control Options section). The build process will be continued if it is true (checked), but the build result will be partially succeeded.
You also can output the error or warning by using PowerShell or VSTS task commands (uncheck Fail on Standard Error option in the Advanced section) and terminate the current PowerShell process by using the exit keyword, for example:
Write-Warning “warning”
Write-Error “error”
Write-Host " ##vso[task.logissue type=warning;]this is the warning"
Write-Host " ##vso[task.logissue type=error;sourcepath=consoleapp/main.cs;linenumber=1;columnnumber=1;code=100;]this is an error "
More information about the VSTS task command, you can refer to: Logging Commands
When putting together a release definition in VSO, adding an Azure PowerShell
task
backed by a file Script1.ps only containing exit 1 does not fail the step when it runs - which I would expect it to do, given that the Continue on error box is not checked
If I add the PowerShell task, writing exit 1 using the inline variant would indeed fail the step. This also comes with an 'advanced configuration option' where the Fail on Standard Error is checked by default.
What did I miss? How would I go about making the Azure Powershell fail in the same manner?
Using this code instead:
[Environment]::Exit(1)
The task will fail if the script throws an exception or writes to stderr stream.
I have a powershell file test.ps1 which takes 3 parameters. I am trying to call/execute this file from a script step/task in octopus.
Can I do this, if I can how to achieve this.
I tried a few things to achieve this.
Use a batch file (test.bat) powershell E:\somefolder\test.ps1 %1 %2 %3 to call the below in the script task in octopus to execute this E:\somefolder\test.bat p1 p2 p3
The above does not work and says cmdlet does not identify the command.
Use the ps1 file itself i.e. call E:\somefolder\test.ps1 p1 p2 p3 to call in the script task in octopus.
This gives the same error as above.
I changed the code a little bit to use param([string]$param1, [string]$param2, [string]$param3) and then I get the parameter cannot be found.
Can someone please help me with this issue.
In Octopus Deploy you can use a "Run Script" step to execute scripts. This step is designed to execute PowerShell on the deployment target, which removes the need to find ways of kicking of the script. It also means that the step becomes part of the deployment process and you can end the deployment if it fails.
In the nextversion of Octopus Deploy (v3.3) you can have your PowerShell script in source control, or you can edit the script in the step itself. You have access to project variables and Octopus system variables in the script.
In previous versions, only the option to edit the script within the step was available.
Go to your Project's process in Ocotpus Deploy and...
Click "Add step"
Select "Run a Script"
Give it a name and enter the PowerShell script
Add any conditions
Click "Save"
I have a build configuration in TFS 2013 that produces versioned build artifacts. This build uses the out of the box process template workflow. I want to destroy the build artifacts in the event that unit tests fail leaving only the log files. I have a Post-Test powershell script. How do I detect the test failure in this script?
Here is the relevant cleanup method in my post-test script:
function Clean-Files($dir){
if (Test-Path -path $dir) { rmdir $dir\* -recurse -force -exclude logs,"$NewVersion" }
if(0 -eq 1) { rmdir $dir\* -recurse -force -exclude logs }
}
Clean-Files "$Env:TF_BUILD_BINARIESDIRECTORY\"
How do I tests for test success in the function?
(Updated based on more information)
The way to do this is to use environment variables and read them in your PowerShell script. Unfortunately the powershell scripts are run in a new process each time so you can't rely on the environment variables being populated.
That said, there is a workaround so you can still get those values. It involves calling a small utility at the start of your powershell script as described in this blog post: http://blogs.msmvps.com/vstsblog/2014/05/20/getting-the-compile-and-test-status-as-environment-variables-when-extending-tf-build-using-scripts/
This isn't a direct answer, but... We just set the retention policy to only keep x number of builds. If tests fail, the artifacts aren't pushed out to the next step.
With our Jenkins setup, it wipes the artifacts every new build anyway, so that isn't a problem. Only the passing builds fire the step to push the artifacts to the Octopus NuGet server.
The simplest possible way (without customizing the build template, etc.) is do something like this in your post-test script:
$testRunSucceeded = (sqlcmd -S .\sqlexpress -U sqlloginname -P passw0rd -d Tfs_DefaultCollection -Q "select State from tbl_TestRun where BuildNumber='$Env:TF_BUILD_BUILDURI'" -h-1)[0].Trim() -eq "3"
Let's pull this apart:
sqlcmd.exe is required; it's installed with SQL Server and is in the path by default. If you're doing builds on a machine without SQL Server, install the Command Line Utilities for SQL Server.
-S parameter is server + instance name of your TFS server, e.g. "sqlexpress" instance on the local machine
Either use a SQL login name/password combo like my example, or give the TFS build account an account on SQL Server (preferred). Grant the account read-only access to the TFS instance database.
The TFS instance database is named something like "Tfs_DefaultCollection".
The "-h-1" part at the end of the sqlcmd statement tells sqlcmd to output the results of the query without headers; the [0] selects the first result; Trim() is required to remove leading spaces; State of "3" indicates all tests passed.
Maybe someday Microsoft will publish a nice REST API that will offer access to test run/result info. Don't hold your breath though -- I've been waiting six years so far. In the meantime, hitting up the TFS DB directly is a safe and reliable way to do it.
Hope this is of some use.