Here is my problem. I'm running TestRunner from command line in order not to launch SoapUI client. (anyway, same problem occurs when running TR straight from client, so not sure if worth mentioning but anyways...). I do it this way:
testrunner <path_to_project> -r -a -f <path_to_reports> & pause
In one of my TC I retrieve data from DB, then save it to project properties this way:
testRunner.testCase.testSuite.project.setPropertyValue("key", value);
Then I use it in next steps which works fine. The problem appears in other TC where, firstly, I get filename from my project properties, this way:
def oldFilename = testRunner.testCase.testSuite.project.getPropertyValue("FILE_NAME");
Then I want to use it, rename it and save to project properties again, so that it would be ready for next launch. I do it the same way:
testRunner.testCase.testSuite.project.setPropertyValue("FILE_NAME", newFilename);
It seems to be not saving/storing this value. Is there any way to fix this?
If you modify anything in your project, and you want to preserve that from one run to the next, use the -S (uppercase) switch.
Documentation is your friend. :)
Related
I'm trying to learn how autocompletion works in zsh. I've got a simple script file (example.zsh) and I'm trying to create a simple autocomplete function that describes each of its parameters. In order to do that, I've started by creating a simple _example file which looks like this:
#compdef create_ca
_arguments \
"--caKey[name of the file that will hold the keys used for generating the certificate (default: ca.key)]" \
"--caCrt[name of the file that will hold the certificate with the public key (default: ca.crt)]" \
"--cn[common name for the root certificate (default: root.GRM)]" \
"--days[number of days that certificate is valid for (default: 10500)]" \
"--size[key size (default: 4096)]" \
"--help[show this help screen]"
The file is on the same folder as the script and I've updated my .zshrc file so that it adds that folder to the $fpath:
fpath=(~/code/linux_certificates $fpath)
autoload -Uz compinit
compinit -D
I'm using the D option so that the .zcompdump isn't generated. At first sight, everything worked out, but when I tried to update the helper autocomplete function, I'm unable to see thosee changes (ex.: changing the description). I've tried re-running the compinit command and, when using the cache .zcompdump, deleting that file. However, it simply didn't work. The only way I've managed to get it working was by deleting the autocomplete helper function with:
unfunction _create_ca
Is this the expected behavior? I mean, should't running compinit -D be enough to reload my helper autocomplete function?
btw, any good tutorials on how to create autocomplete functions (besides the official docs)?
thanks.
Once a function has been loaded, it will not be loaded again. That’s why you first have to unfunction your function, causing Zsh to unload it, so it can be loaded again.
Alternatively, you can just use exec zsh to restart your shell.
I like to execute a command line programm as a DAM workflow. I tried to implement the ImageMagic example from here: Best Practices for Configuring ImageMagick:
I addded a new Workflow Model,
added "command line" from the "DAM Workflow" list.
In the Argument tab set Mime type to "image/jpeg" (even tried wihtout Mime type)
and in Commands: "C:\Program Files\ImageMagick-7.0.7-Q16\magick.exe" convert ${file} -flip ${file}-flipped.jpg (instead of magick convet ... because in another discussion using an absolute path instead of global name helped people Re: CommmandLineProcess : ImageMagick)
I then added a luncher. And uploaded an Image to the DAM.
In the workflow > instances overview, i see that the workflow was started, it's running and the command line job is set to active.
Unfortunantly this state is never chnaged and no new asset is generated via imageMagic.
I even tried replacing the command with something simple like "ren C:\test\foo.txt bar.txt" which renames a local file. The chnage never happend either.
My question is what am i doing wrong, and how can i debug / find the command outputs? in \crx-quickstart\logs i couldn't find any logs regarding CommandLineProcess.
Thanx
Ok, so here's my issue. I have written a build script in bash that pipes output to tee and sorts different output to different log files (so I can summarize errors/warnings at the end and get some statistics on files built). I wanted to use the colorgcc perl script (colorgcc.1.3.2) to colorize the output from gcc and had found in other places that this won't work piping to tee, since the script checks if it is writing to something that is not a tty. Having disabled this check everything was working until I did a full build and discovered some of the code we receive from another group builds C dependency files (we don't control this code, changing it or the build process for these isn't really an option).
The problem is that these .d files have the form as follows:
filename.o filename.d : filename.c \
dependant_file1.h \
dependant_file2.h (and so on for however many dependencies there are)
This output from GCC gets written into the .d file, but, since it is close enough to a warning/error message colorgcc outputs color codes (believe it's the check for filename:lineno:message but not 100% sure, could be filename:message check in the GCCOUT while loop). I've tried editing the regex to attempt to not match this but my perl-fu is admittedly pretty weak. So what I end up with is a color code on each line for these dependency files, which obviously causes the build to fail.
I ended up just replacing the check for ! -t STDOUT with a check for a NO_COLOR envar I set and unset in the build script for these directories (emulates the previous behavior of no color for non-tty). This works great if I run the full script, but doesn't if I cd into the directory and just run make (obviously setting and unsetting manually would work but this is a pain to do every time). Anyone have any ideas how to prevent this script from writing color codes into dependency files?
Here's how I worked around this. I added the following to colorgcc to search the gcc input for the flag to generate the .d files and just directly called the compiler in that case. This was inserted in place of the original TTY check.
for each $argnum (0 .. $#ARGV)
{
if ($ARGV[$argnum] =~ m/-M{1,2}/)
{
exec $compiler, #ARGV
or die("Couldn't exec");
}
}
I don't know if this is the proper 'perl' way of doing this sort of operation but it seems to work. Compiling inside directories that build .d files no longer inserts color codes and the source file builds do (both to terminal and my log files like I wanted). I guess sometimes the answer is more hacks instead of "hey, did you try giving up?".
I'm using this article as a source to get me half way there, but I cannot figure out how to run supervisor with a custom config file path.
When I want to run supervisor manually, I just do:
supervisord -c /home/test/_app/supervisord.conf
When I implemented the auto start up script, it runs the default supervisor config file which is located in /etc/ directory. I don't want to use that one because it separates it from the core project folder and makes it hard to maintain and keep track of.
Try this:
In /etc/rc.d/init.d/supervisord, add prog_opts variable like this:
prog_opts=" -c /home/test/_app/supervisord.conf"
prog_bin="${exec_prefix}/bin/supervisord"
Then in start() function, change the call to:
daemon $prog_bin --pidfile $PIDFILE -- $prog_opts
I was able to fix this issue by simply deleting the default supervisord.conf file and then making a sym link with that default location and my custom conf file path.
XCode now keeps the logs from the previous runs handy which is great.
Is there a way to search though all of the logs.
My use case is I have seen a particular error but cant remember which run it was in. I need to find the error URL from the logs.
Xcode stores debug logs at
~/Library/Developer/Xcode/DerivedData/<YOURAPP>/Logs/Debug/
The .xcactivitylog files are actually just gz archives. Decompress them:
cd ~/Library/Developer/Xcode/DerivedData/<YOURAPP>/Logs/Debug/
EXT=".xcactivitylog"
for LOG in *.xcactivitylog; do
NAME=`basename $LOG $EXT`
gunzip -c -S $EXT "${NAME}${EXT}" > "${NAME}.log"
done
Now you can easily search them using grep or Spotlight or what your prefer.
To add onto #DrummerB answer. Once the files are unziped you can do a search with custom scope from within XCode. I prefer this to grep or spotlight.
The folder where these logs are is
~/Library/Developer/Xcode/DerivedData/[YOURAPPID]/Logs/Debug/
You can open/read/search them for example in TextWrangler.