how to fail the GO build based on the sonar quality gate?
I expect the stage to be failed when gateway fails. Is there any configurations that can be done to fail the build
Based on #moritz answer, this worked for me.
I created a bat file that would check for the status code of the SONAR project, after the SONAR build is executed and based on the status of the response, would return the exit code.
For /F "Delims=" %%A In ('"curl http://mysonarserver/api/qualitygates/project_status?projectKey=com.mypackage:sampleproject | jq ".projectStatus.status""') Do Set "test=%%~A"
echo %test%
If /I "%test%"=="ERROR" exit -1
If /I "%test%"=="OK" exit 0
In my case, the SONAR server would return ERROR and OK based on the status of the build.
I have used curl and jq for making the http request from the command line and to parse the response to json respectively.
I had to do some tweaking to make it work on Windows, hopefully it should work on Linux as well.
You can also add the call to the Maven build for Sonar from this script if needed.
I hope it helps!
GoCD fails the task (and thus stage and job, unless configured otherwise) when the exit code is non-zero.
So you need to bring whatever command you are executing to indicate a failure through a non-zero exit code (which most UNIX commands do).
Related
I have a VSTS (Azure DevOps) build which contains a PowerShell or a Command line task. This task is running some program: program.exe. When program.exe returns a non-zero exit code, the build is failed as expected. program.exe also prints a detailed error message to the stderr stream in case of an error.
The problem is that the content of the stderr stream is not passed to the build. The task is always returning the following error message which is also displayed as a build failure message on the build summary tab:
Process completed with exit code 1.
Which is useless. The user has to look for a failed task, open its output and search for an error message there. That's not very convenient.
How to easily pass the content of stderr to the build?
Do I have to manually capture stderr and then send it to the build using PowerShell or is there a setting to change the build behaviour to work as I expect?
I just added "2>&1 | Write-Host" to the command so that the stderr stream will be routed to the Write-Host stream. Reference this thread: VSTS build fails with "Process completed with exit code 0 and had 3 error(s) written to the error stream." even though I set my PowerShell script to ignore errors
You can also try uncheck the Fail on Standard Error in your PowerShell script configuration and write the lastexitcode to pass the task:
Fail on Standard Error
If this is true, this task will fail if any errors are written to the
error pipeline, or if any data is written to the Standard Error
stream. Otherwise the task will rely solely on $LASTEXITCODE and the
exit code to determine failure.
Then you can output the error or warning by using PowerShell or VSTS task commands.
Write-Warning “warning”
Write-Error “error”
Write-Host " ##vso[task.logissue type=warning;]this is the waring"
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
I have reviewed all the Continua CI staging actions, but can't find any to force build process to fail. "Stop" build action is just executed with "Success" state. Have I missed something?
Update
Continua CI server version is 1.5.0.338. This solution is not applicable http://wiki.finalbuilder.com/display/continua/Stop+Action
You can use the Stop Action to fail a build, just uncheck the "As Success" option.
Found workaround using "Run DOS Command / Batch File" with command set to:
EXIT /B 1
When I'm compiling ism project to create MSI, its still creates the MSI even though I have build errors.
The reason I need it NOT to be created is for build verification.
Instead of checking the build log for errors, I will just check the existence of the MSI.
Does anybody know how can I achieve that?
EDIT:
I'm using ISCmdBld tool to build MSIs. This is the command line I'm running to build where the environment variables are being set before running this command:
IsCmdBld -p "%FULL_PROJECT_FILENAME%" -a %BUILDMODE% -r %PRODUCT% -o "%MMSEARCHPATH%" | tee /A "%FULL_PROJECT_LOG_FILENAME%"
If you are compiling using IsCmdBld.exe, you should add the -x option, so that the build is stopped if an error occurs.
You also can use it combined with -w, which makes each warning becomes considered as an error (and thus, each warning encountered also stops the build).
More information about IsCmdBld.exe : http://helpnet.installshield.com/installshield16helplib/ISCmdBldParam.htm
I hope this helps.
Your build automation should check the exit code from ISCmdBld.exe. If the exit code is a failure, don't archive the output.
I am having problems with Teamcity, where it is proceeding to run build steps even if the previous ones were unsuccessful.
The final step of my Build configuration deploys my site, which I do not want it to do if any of my tests fail.
Each build step is set to only execute if all previous steps were successful.
In the Build Failure Conditions tab, I have checked the following options under Fail build if:
-build process exit code is not zero
-at least one test failed
-an out-of-memory or crash is detected (Java only)
This doesn't work - even when tests fail TeamCity deploys my site, why?
I even tried to add an additional build failure condition that will look for specific text in the build log (namely "Test Run Failed.")
When viewing a completed test in the overview page, you can see the error message against the latest build:
"Test Run Failed." text appeared in build log
But it still deploys it anyway.
Does anyone know how to fix this? It appears that the issue has been running for a long time, here.
Apparently there is a workaround:
So far we do not consider this feature as very important as there is
an obvious workaround: the script can check the necessary condition
and do not produce the artifacts as configured in TeamCity.
e.g. a script can move the artifacts from a temporary directory to the
directory specified in the TeamCity as publish artifacts from just
before the finish and in case the build operations were successful.
But that is not clear to me on exactly how to do that, and doesn't sound like the best solution either. Any help appreciated.
Edit: I was also able to workaround the problem with a snapshot dependency, where I would have a separate 'deploy' build that was dependent on the test build, and now it doesn't run if tests fail.
This was useful for setting the dependency up.
This is a known problem as of TeamCity 7.1 (cf. http://youtrack.jetbrains.com/issue/TW-17002) which has been fixed in TeamCity 8.x+ (see this answer).
TeamCity distinguishes between a failed build and a failed build step. While a failing unit test will fail the build as a whole, unfortunately TeamCity still considers the test step itself successful because it did not return a non-zero error code. As a result, subsequent steps will continue running.
A variety of workarounds have been proposed, but I've found they either require non-trivial setup or compromise on the testing experience in TeamCity.
However, after reviewing a suggestion from #arex1337, we found an easy way to get TeamCity to do what we want. Just add an extra Powershell build step after your existing test step that contains the following inline script (replacing YOUR_TEAMCITY_HOSTNAME with your actual TeamCity host/domain):
$request = [System.Net.WebRequest]::Create("http://YOUR_TEAMCITY_HOSTNAME/guestAuth/app/rest/builds/%teamcity.build.id%")
$xml = [xml](new-object System.IO.StreamReader $request.GetResponse().GetResponseStream()).ReadToEnd()
Microsoft.PowerShell.Utility\Select-Xml $xml -XPath "/build" | % { $status = $_.Node.status }
if ($status -eq "FAILURE") {
throw "Failing this step because the build itself is considered failed. This is our way to workaround the fact that TeamCity incorrectly considers a test step to be successful even if there are test failures. See http://youtrack.jetbrains.com/issue/TW-17002"
}
This inline PowerShell script is just using the TeamCity REST API to ask whether or not the build itself, as a whole, is considered failed (the variable %teamcity.build.id%" will be replaced by TeamCity with the actual build id when the step is executed). If the build as a whole is considered failed (say, due to a test failure), then this PowerShell script throws an error, causing the process to return a non-zero error code which results in the individual build step itself to be considered unsuccessful. At that point, subsequent steps can be prevented from running.
Note that this script uses guestAuth, which requires the TeamCity guest account to be enabled. Alternately, you can use httpAuth instead, but you'll need to update the script to include a TeamCity username and password (e.g. http://USERNAME:PASSWORD#YOUR_TEAMCITY_HOSTNAME/httpAuth/app/rest/builds/%teamcity.build.id%).
So, with this additional step in place, all subsequent steps set to execute "Only if all previous steps were successful" will be skipped if there are any previous unit test failures. We're using this to prevent automated deployment if any of our NUnit tests are not successful until JetBrains fixes the problem.
Thanks to #arex1337 for the idea.
Just to prevent confusion, this issue is fixed in Team City v8.x, We don't need those workarounds now.
You can specify the step execution policy via the Execute step option:
Only if build status is successful - before starting the step, the build agent requests the build status from the server, and skips the step if the status is failed.
https://confluence.jetbrains.com/display/TCD8/Configuring+Build+Steps
Of course you need to fail the build if at least one unit test failed:
https://confluence.jetbrains.com/display/TCD8/Build+Failure+Conditions
On the Build Failure Conditions page, the Fail build if area, specify when TeamCity will fail builds:
at least one test failed: Check this option to mark the build as failed if the build fails at least one test.
This is (as you have found) a known issue with TeamCity, there are a set of linked issues in their Issue Tracker. This issue is hopefully scheduled to be resolved in the next release of TeamCity (version 8.x)
In the mean time, the way we identified to resolve the issue (for version 6.5.5) was to download the test results file as part of the later steps. This was then parsed to check for any test failures, returning an error code and hence breaking the build properly (performing any cleanup we needed as part of that failure) which would probably work for you.
TeamCity build failure does not mean that it will stop the build and it will publish the artifacts if your build is providing the the build output files as required by TeamCity. It will only update the build status properly.
But, you can very well stop the build process by modification to your build script to stop the build on test case failure. If you are using MSBuild, then ContinueOnError="false" will do that.
In the end, I was able to solve the problem with a snapshot dependency, where I would have a separate 'deploy' build that was dependent on the test build, and now it doesn't run if tests fail.
This was useful for setting the dependency up.
I would like to process some operations only if the build failed. For example, if runtime execution has thrown a core dump (it doesn't happen always, of course) and I want to move it somewhere, so that the next day build won't remove it.
Does anyone know how to perform anything in case a build fails?
Try Groovy Postbuild Plugin. With this you can use hudson api's to check if the build is a failure or not, and then do the required actions using groovy script. For example, you can use following script to check if the build is unstable or better
if(manager.build.result.isBetterOrEqualTo(hudson.model.Result.UNSTABLE))
{
\\ do something
}
Well if it is set up to log to std out, it will be in the Jenkins log, if not, can you set it up to log to a file in you workspace , then you can package as an artifact based on the name... If you are running in a posix system you can redirect stderr to stdout and direct those both to a file in your run command. Or pipe them through tee, so you get them in both