How to run Grunt more silent?
I don't have the --verbose option on. Still I get a long log.
I would like to have a shorter log, ideally just log the failed specs.
Any suggestion?
I am using grunt-karma and Jasmine
update
After some discussions in comments below I think you could do something like:
grunt test | grep should\|Expected > logs.txt
This way you'll get only the lines containing "should" or "Expected" in the log file.
Adapt this expression to match the lines you want to keep.
My first answer was:
Just redirect the output
Assuming your task is named 'test'
under OS X / Linux:
grunt test > /dev/null
under windows command line:
grunt test > NUL
Or you can change your configuration and set options.silently to true. Take a look to the grunt-serve npm page
Related
Is there any reason that the below command does this and is there any way to stop it appending it? Code
Run And Return Rc cat ${files_to_process_path}${FILE}
Outputs...
16:47:26.424 TRACE Arguments: [ 'cat /var/www/sponsor1_integration/to_process/study-6313_LONGBOAT_20170112_12:37.csv' ]
16:47:26.428 INFO Running command 'cat /var/www/sponsor1_integration/to_process/study-6313_LONGBOAT_20170112_12:37.csv 2>&1'.
16:47:26.431 TRACE Return: 0
It is appended, so any error output of a shell command is propagated back to your keywords - i.e. not to hide it. The construct 2>&1 does just that - redirects stder to stdout.
As for removing it - no, it's embedded too deep in the OperatingSystem library, with no control to not use it.
If you really don't want it, you should create your own library for that. Though, it does not do any harm, on the contrary, its benefit is you'll see any errors from the commands.
I'm trying to execute a command remotely through Robot Framework which is failing through Robot framework and giving me the wrong exit status of 13.
But if we run this manually exit status of TTman.sh is 112 which is actually pass(Not the standard return codes).
am I doing something wrong here?
You are not getting the remote code of the remote command, in fact the RC 13 you are getting from the run is most probably from the robotframework - on run completion its RC is the number of failed cases. I.e. 13 cases should have failed, when you observed this.
To get the return code of your command, a few changes in the case are needed; this is how the semi-last line should look like, with explanations below:
${rc}= Execute Command your_command_from_the_question &>/dev/null; echo $?
First, all the output of your command (stdout & stderr) is redirected to /dev/null - to not return it. Then the special var $? is printed - it holds the RC of the last executed command (and is available in most *sh variants, like bash).
Finally, that value is stored in the ${rc} robotframework variable, and you can do whatever checks you need on it, further in the case.
This approach has one drawback - as stderr is hidden, you will not be able to see any errors coming from running the command. But if it was not, then they would be interleaved with the RC, which would have required further processing of the {rc} var, to get the desired value. If you need it (the stderr output in case of failures), change accordingly.
P.S. don't add screenshots of a source in a question, it is much less usable than a text version.
I am struggling with running new asp.net 5 on my qnap box. As far as I understand it is a strongly modified version of debian.
As part of running installation script I got this error:
-sh: /root/.dnx/dnvm/dnvm.sh: line 616: syntax error near unexpected token `<'
-sh: /root/.dnx/dnvm/dnvm.sh: line 616: read versionOrAlias downloadUrl < <(__dnvm_find_latest "$runtime" "$arch" "$os")'
I run my script bu using script command like:
script /root/.dnx/dnvm/dnvm.sh
as stated in documentation and previous installation script.
By commenting this line out I was able to run whole script but obviously dnvm command does not work properly.
My question is:
What does it do (line with < < syntax) and how do I fix it or rewrite so that my qnap box unix can understand it.
<(...) is Process substitution. /bin/sh doesn't support it, but /bin/bash does. Try changing the shell.
I'm on windows. To build my application I used to do a lot of manual file manipulations and, at the last step, to run this command:
"c:\Program Files\Inno Setup 5\ISCC.exe" /dType=server /dBits=32 /dArchAllowed="x86 x64" config.iss
Please note that the /d option is to pass some custom variables to Inno Setup.
Recently things changed and we decided to automate the task using Grunt. All the file manipulations are working fine. But I'm not able to do the last step (to run the command line) correctly.
I tried:
grunt.task.registerTask('create-exe', 'create the installer', spawnTask({
cmd: 'c:\\Program Files\\Inno Setup 5\\ISCC.exe',
args: ['/dType=server' , '/dBits=32' ,'/dArchAllowed="x86 x64"', 'config.iss' ]
}));
But Inno Setup is not happy:
stderr: 'Error on line 38 in config.iss:
Value of [Setup] section directive "ArchitecturesAllowed" is invalid.',
So, something is wrong with the argument /dArchAllowed="x86 x64" (and if I remove it it is running. But I need this argument.) It's a nasty one: it has double quotes, equal and space! I tried a lot of combinations to escape the special characters but without success.
Any Idea? Thanks!
I found the answer on this help page.
The /d command line compiler parameter values cannot be surrounded by double quotes. So, I just replaced '/dArchAllowed="x86 x64"' with '/dArchAllowed=x86 x64' in the args property.
The whole grunt task is:
grunt.task.registerTask('create-exe', 'create the installer', spawnTask({
cmd: 'c:\\Program Files\\Inno Setup 5\\ISCC.exe',
args: ['/dType=server' , '/dBits=32' ,'/dArchAllowed=x86 x64', 'config.iss' ]
}));
I am building a Qt GUI application via Jenkins. I added 3 build steps:
Building the test executable
Running the test executable
compiling a coverage report with gcovr
For some reason, the shell task for running the test executable stops after execution. Even a simple echo does not run after. The tests are written with Google Test and output xUnit XML files, which are analyzed after the build.
Some tests start the applications user interface, so I installed the jenkins xvnc plugin to get them to run.
The build tasks are as follows:
Build
cd $WORKSPACE/projectfiles/QMake
sh createbin.sh
Test
cd $WORKSPACE/bin
./Application --gtest_output=xml
Coverage Report
cd $WORKSPACE/projectfiles/QMake/out
gcovr -x -o coverage.xml
Now, an echo at the end of the first build task is correctly printed, but an echo at the end of the second is not. The third build task is therefore not even run, although the Google Test output is visible. I thought that maybe the problem is that some of the Google Tests fail, but why whould the script stop executing just because the tests fail?
Maybe someone can give me a hint on why the second task stops.
Edit
The console output looks like this:
Updating svn://repo/ to revision '2012-11-15T06:43:15.228 -0800'
At revision 2053
no change for svn://repo/ since the previous build
Starting xvnc
[VG5] $ vncserver :10
New 'ubuntu:10 (jenkins)' desktop is ubuntu:10
Starting applications specified in /var/lib/jenkins/.vnc/xstartup
Log file is /var/lib/jenkins/.vnc/ubuntu:10.log
[VG5] $ /bin/sh -xe /tmp/hudson7777833632767565513.sh
+ cd /var/lib/jenkins/workspace/projectfiles/QMake
+ sh createbin.sh
... Compiler output ...
+ echo Build Done
Build Done
[VG5] $ /bin/sh -xe /tmp/hudson4729703161621217344.sh
+ cd /var/lib/jenkins/workspace/VG5/bin
+ ./Application --gtest_output=xml
Xlib: extension "XInputExtension" missing on display ":10".
[==========] Running 29 tests from 8 test cases.
... Test output ...
3 FAILED TESTS
Build step 'Execute shell' marked build as failure
Terminating xvnc.
$ vncserver -kill :10
Killing Xvnc4 process ID 1953
Recording test results
Skipping Cobertura coverage report as build was not UNSTABLE or better ...
Finished: FAILURE
Generally, if one Build Step fails, the rest will not be executed.
Pay attention to this line from your log:
[VG5] $ /bin/sh -xe
The -x makes the shell print each command in console before execution.
The -e makes the shell exit with error if any of the commands failed.
A "fail" in this case, would be a return code of not 0 from any of the individual commands.
You can verify this by running this directly on the machine:
./Application --gtest_output=xml
echo $?
If the echo $? displays 0, it indicates successful completion of the previous command. If it displays anything else, it indicates an error code from the previous command (from ./Application), and Jenkins treats it as such.
Now, there are several things at play here. First is that your second Build Step (essentially a temporary shell script /tmp/hudson4729703161621217344.sh) is set to fail if one command fails (the default behaviour). When the Build Step fails, Jenkins will stop and fail the whole job.
You can fix this particular behaviour by adding set +e to the top of your second Build Step. This will not cause the script (Build Step) to fail due to individual command failure (it will display an error for the command, and continue).
However, the overall result of the script (Build Step) is the exit code of the last command. Since in your OP, you only have 2 commands in the script, and the last is failing, it will cause the whole script (Build Step) to be considered a failure, despite the +x that you've added. Note that if you add an echo as the 3rd command, this would actually work, since the last script command (echo) was successful, however this "workaround" is not what you need.
What you need is proper error handling added to your script. Consider this:
set +e
cd $WORKSPACE/bin && ./Application --gtest_output=xml
if ! [ $? -eq 0 ]; then
echo "Tests failed, however we are continuing"
else
echo "All tests passed"
fi
Three things are happening in the script:
First, we are telling shell not to exit on failure of individual commands
Then i've added basic error handling in the second line. The && means "execute ./Application if-and-only-if the previous cd was successful. You never know, maybe the bin folder is missing, or whatever else can happen. BTW, the && internally works on the same error code equals 0 principle
Lastly, there is now proper error handling for the result of ./Application. If the result is not 0, then we show that it had failed, else we show that it had passed. Note, this since the last command is not a (potentially) failing ./Application, but an echo from either of if-else possibilities, the overall result of the script (Built Step) will be a success (i.e 0), and the next Build Step will be executed.
BTW, you can as well put all 3 of your build steps into a single build step with proper error handling.
Yes... this answer may be a little longer than what's required, but i wanted you to understand how Jenkins and shell treat exit codes.