I am trying to export htmlextra report as well as xml. But in below command its only exporting prod_report.xml file but not Prod_TestReport.html.
newman run Test.postman_collection.json -e Test.postman_environment.json -r htmlextra --reporter-htmlextra-export "newman/Prod_TestReport.html" -r cli,junit --reporter-junit-export "newman/prod_report.xml"
But if I try to export htmlreport and xml individually its working fine. Like:
newman run Test.postman_collection.json -e
Test.postman_environment.json -r cli,junit --reporter-junit-export
"newman/prod_report.xml"
newman run Test.postman_collection.json -e
Test.postman_environment.json -r htmlextra
--reporter-htmlextra-export "newman/Prod_TestReport.html"
newman run Test.postman_collection.json -e Test.postman_environment.json -r cli,junit,htmlextra --reporter-junit-export "newman/prod_report.xml" --reporter-htmlextra-export "newman/Prod_TestReport.html"
you should pass all reporters -r , and individual flags --reporter--export can be given in any order, the reporters will consider flags that applicable to them
Related
I want to run a temporary docker and execute several command in it:
.PHONY : Test
Test:
#echo Starting Docker container
/home/pagl_home/bin/SI.docker_17cy/bin/pagl-build-env run -b '$(PRJ_BUILD_TREE)' -w '$(PRJ_WORK_DIR)' --objdir '' -c 'rm -rf build_results; \
make clean_brutal; \
$(PRJ_MISRA_CMD)/cov-build --dir build_results --encoding UTF-8 make SUB_PRODUCT=$(SUB_PRODUCT); \
$(if $(COVERITY_MISRA_2012), \
$(PRJ_test_CMD)/cov-analyze --dir build_results --disable-default --coding-standard-config /home/XX/XX-linux64-2018.06/config/coding-standards/XX/XX-all.config --paths 100000 --tu-pattern "file('.*\.c$\')"; \
$(PRJ_test_CMD)/cov-format-errors --dir build_results --html-output build_results/results/HTML_2012, );'
but I het the following error:
Illegal character in pattern: .
[ERROR] No results found.
I want to know how to run command seperately in a running container?
like:
.PHONY : Test
Test:
#echo Starting Docker container
/home/pagl_home/bin/SI.docker_17cy/bin/pagl-build-env run -b '$(PRJ_BUILD_TREE)' -w '$(PRJ_WORK_DIR)' --objdir '' -c 'rm -rf build_results; \
/home/pagl_home/bin/SI.docker_17cy/bin/pagl-build-env run -c 'make clean_brutal';
/home/pagl_home/bin/SI.docker_17cy/bin/pagl-build-env run -c '$(PRJ_MISRA_CMD)/cov-build --dir build_results --encoding UTF-8 make SUB_PRODUCT=$(SUB_PRODUCT)'
/home/pagl_home/bin/SI.docker_17cy/bin/pagl-build-env run -c '$(if $(FFFF), \
/home/pagl_home/bin/SI.docker_17cy/bin/pagl-build-env run $(PRJ_test_CMD)/cov-analyze --dir build_results --disable-default --coding-standard-config /home/XX/XX-linux64-2018.06/config/coding-standards/XX/XX-all.config --paths 100000 --tu-pattern "file('.*\.c$\')"'
/home/pagl_home/bin/SI.docker_17cy/bin/pagl-build-env run -c '$(PRJ_test_CMD)/cov-format-errors --dir build_results --html-output'build_results/results/HTML_2012, );'
I know this doesn't work but to give an idea what I want to do
I can't for the life of me figure out why -Xmx in MAVEN_OPTS doesn't work for Maven in openjdk:8-jdk-alpine.
This:
$ docker run --rm openjdk:8-jdk-alpine sh -c 'apk add maven && MAVEN_OPTS=-Xmx2g\ -Xms2g mvn --version'
Produces:
Error occurred during initialization of VM
Initial heap size set to a larger value than the maximum heap size
I've used -XX:+PrintFlagsFinal to look at MaxHeapSize with various settings and here's what I found:
Apparently -Xmx is fixed to 512mb regardless of what's specified. Other options such as -Xms and -XX:+PrintFlagsFinal work as expected:
$ docker run --rm openjdk:8-jdk-alpine sh -c 'apk add maven && \
MAVEN_OPTS="-Xmx123m -Xms123m -XX:+PrintFlagsFinal" mvn --version | egrep "(Initial|Max)HeapSize"'
uintx InitialHeapSize := 130023424 {product}
uintx MaxHeapSize := 536870912 {product}
apt add maven is installing maven version 3.6.0-r0 but trying with other versions also produce the same result. For example, 3.6.1-r0 in Alpine 3.10 and 3.5.2-r0 in Alpine 3.7 produced the same result:
$ docker run openjdk:8-jdk-alpine sh -c 'sed -e s:/v3.9/:/v3.10/: /etc/apk/repositories -i && \
apk add maven && MAVEN_OPTS=-Xmx2g\ -XX:+PrintFlagsFinal mvn -version | fgrep MaxHeapSize'
I've looked for ~/.m2/settings.xml and ./.mvn as mentioned in https://maven.apache.org/configure.html but neither seem to exist:
$ docker run --rm openjdk:8-jdk-alpine sh -c 'apk add maven && ls ~/.m2'
java seems to support -Xmx fine:
$ docker run --rm openjdk:8-jdk-alpine sh -c 'java -Xmx2g -XX:+PrintFlagsFinal -version | fgrep MaxHeapSize'
The problem doesn't occur if maven:3.6.0-jdk-8-alpine is used instead of openjdk:8-jdk-alpine:
$ docker run --rm maven:3.6.0-jdk-8-alpine sh -c \
'MAVEN_OPTS=-Xmx2g\ -XX:+PrintFlagsFinal mvn --version | fgrep MaxHeapSize'
Using _JAVA_OPTIONS instead of MAVEN_OPTS works as a workaround:
$ docker run --rm openjdk:8-jdk-alpine sh -c 'apk add maven && \
_JAVA_OPTIONS=-Xmx2g\ -XX:+PrintFlagsFinal mvn --version | fgrep MaxHeapSize'
Question is, how is -Xmx in MAVEN_OPTS being ignored for Maven in openjdk:8-jdk-alpine?
This obscure problem is documented in this equally hard to find bug report. Basically, Maven on Alpine Linux is packaged with an /etc/mavenrc file containing these lines:
M2_HOME="$m2_home"
MAVEN_OPTS="\$MAVEN_OPTS -Xmx512m"
The problem lies in the second line which hard codes -Xmx to 512m. So yes, -Xmx cannot be set through MAVEN_OPTS on Alpine Linux's vanilla Maven as of time of writing.
To test, simply remove the file and try again:
$ docker run --rm openjdk:8-jdk-alpine sh -c 'apk add maven && rm /etc/mavenrc && \
MAVEN_OPTS=-Xmx2g\ -XX:+PrintFlagsFinal mvn --version | fgrep MaxHeapSize'
MaxHeapSize should then be set to the desired 2g.
The bug report is three years old and probably hasn't gained more traction because there's couple of conditions that need satisfying: Using Maven on Alpine Linux and requiring more than 512m to build.
A person who stumbles on this has few options:
Use _JAVA_OPTIONS instead of MAVEN_OPTS for setting -Xmx
Remove the second line of /etc/mavenrc
Hopefully for them, an OOM error will come quickly and painlessly, instead of extremely slow builds due to excessive GC'ing.
I am using security scan software in my Dockerfile and I need to add its bin folder to the path. Its path will contain the version part so I do not know the path until I download the software. My current progress is something like this:
1.Download the software:
RUN curl https://cloud.appscan.com/api/SCX/StaticAnalyzer/SAClientUtil?os=linux --output SAClientUtil.zip
RUN unzip SAClientUtil.zip -d SAClientUtil
2.The desired folder is located: SAClientUtil/SAClientUtil.X.Y.Z/bin/ (xyz mary vary from run to run). Get there using find and cd combination and try to add it to the PATH:
RUN cd "$(dirname "$(find SAClientUtil -type f -name appscan.sh | head -1)")"; \
export PATH="$PATH:$PWD"; # doesn't work
Looks like ENV command is not evaluating the parameter, so
ENV PATH $PATH:"echo $(dirname "$(find SAClientUtil -type f -name appscan.sh | head -1)")"
doesn't work also.
Any ideas on how to dynamically add a folder to the PATH during docker image build?
If you're pretty sure the zip file will contain only a single directory with that exact layout, you can rename it to something fixed.
RUN curl https://cloud.appscan.com/api/SCX/StaticAnalyzer/SAClientUtil?os=linux --output SAClientUtil.zip \
&& unzip SAClientUtil.zip -d tmp \
&& mv tmp/SAClientUtil.* SAClientUtil \
&& rm -rf tmp SAClientUtil.zip
ENV PATH=/SAClientUtil/bin:${PATH}
A simple solution would be to include a small wrapper script in your image, and then use that to run commands from the SAClientUtil directory. For example, if I have the following in saclientwrapper.sh:
#!/bin/sh
cmd=$1
shift
saclientpath=$(ls -d /SAClientUtil/SAClientUtil.*)
echo "got path: $saclientpath"
cd "$saclientpath"
exec "$saclientpath/bin/$cmd" "$#"
Then I can do this:
RUN curl https://cloud.appscan.com/api/SCX/StaticAnalyzer/SAClientUtil?os=linux --output SAClientUtil.zip
RUN unzip SAClientUtil.zip -d SAClientUtil
COPY saclientwrapper.sh /saclientwrapper.sh
RUN sh /saclientwrapper.sh appscan.sh
And this will produce, when building the image:
STEP 6: RUN sh /saclientwrapper.sh appscan.sh
got path: /SAClientUtil/SAClientUtil.8.0.1374
COMMAND SYNTAX
appscan <command> [options]
ADDITIONAL COMMAND HELP
appscan help <command>
.
.
.
When issuing grunt shell:test, I'm getting warning "the input device is not a TTY" & don't want to have to use -f:
$ grunt shell:test
Running "shell:test" (shell) task
the input device is not a TTY
Warning: Command failed: /bin/sh -c ./run.sh npm test
the input device is not a TTY
Use --force to continue.
Aborted due to warnings.
Here's the Gruntfile.js command:
shell: {
test: {
command: './run.sh npm test'
}
Here's run.sh:
#!/bin/sh
# should use the latest available image to validate, but not LATEST
if [ -f .env ]; then
RUN_ENV_FILE='--env-file .env'
fi
docker run $RUN_ENV_FILE -it --rm --user node -v "$PWD":/app -w /app yaktor/node:0.39.0 $#
Here's the relevant package.json scripts with command test:
"scripts": {
"test": "mocha --color=true -R spec test/*.test.js && npm run lint"
}
How can I get grunt to make docker happy with a TTY? Executing ./run.sh npm test outside of grunt works fine:
$ ./run.sh npm test
> yaktor#0.59.2-pre.0 test /app
> mocha --color=true -R spec test/*.test.js && npm run lint
[snip]
105 passing (3s)
> yaktor#0.59.2-pre.0 lint /app
> standard --verbose
Remove the -t from the docker run command:
docker run $RUN_ENV_FILE -i --rm --user node -v "$PWD":/app -w /app yaktor/node:0.39.0 $#
The -t tells docker to configure the tty, which won't work if you don't have a tty and try to attach to the container (default when you don't do a -d).
This solved an annoying issue for me. The script had these lines:
docker exec **-it** $( docker ps | grep mysql | cut -d' ' -f1) mysql --user= ..... > /var/tmp/temp.file
mutt -s "File is here" someone#somewhere.com < /var/tmp/temp.file
The script would run great if run directly and the mail would come with the correct output. However, when run from cron, (crontab -e) the mail would come with no content. Tried many things around permissions and shells and paths etc. However no joy!
Finally found this:
*/20 * * * * scriptblah.sh > $HOME/cron.log 2>&1
And on that cron.log file found this output:
the input device is not a TTY
Search led me here. And after I removed the -t, it's working great now!
docker exec **-i** $( docker ps | grep mysql | cut -d' ' -f1) mysql --user= ..... > /var/tmp/temp.file
I am able to create a model in MOA(Weka) for case 1 but not for "case 2" (same data set). Could anyone explain why?
Case 1 (IBk/LWL):
java -cp moa.jar:weka.jar -javaagent:sizeofag.jar moa.DoTask "LearnModel -l (meta.WEKAClassifier -l (weka.classifiers.lazy.IBk)) -s (ArffFileStream -f training_s2w.arff -c 1) -O model.moa"
java -cp moa.jar:weka.jar -javaagent:sizeofag.jar moa.DoTask "EvaluateModel -m file:model.moa -s (ArffFileStream -f test_s2w.arff -c 1) -o predicted.txt"
Above two commands creates a model and apply it on test data successfully.
Case 2 (SMO/J48/NaiveBayes/BayesNet):
java -cp moa.jar:weka.jar -javaagent:sizeofag.jar moa.DoTask "LearnModel -l (meta.WEKAClassifier -l (weka.classifiers.functions.SMO)) -s (ArffFileStream -f training_s2w.arff -c 1) -O model.moa"
java -cp moa.jar:weka.jar -javaagent:sizeofag.jar moa.DoTask "EvaluateModel -m file:model.moa -s (ArffFileStream -f test_s2w.arff -c 1) -o predicted.txt"
But these two commands gives output as:
"Model description:
SMO: No model built yet"
(I checked through Weka CLI that both training and test data is Weka compatible.)
What could be the possible reason(s)?