In the steps of setting up CI builds on our gitlab server, I can't seem to find information on how to set up the detection of compiler warnings. Example build output:
[100%] Building CXX object somefile.cpp.o
/home/gitlab-runner/builds/XXXXXXX/0/group/project/src/somefile.cpp:14:2: warning: #warning ("This is a warning to test gitlab") [-Wcpp]
#warning("This is a warning to test gitlab")
^
However the build result is success instead of warning or something similar. Ideally the results wuold also be visible on the merge request on the feature (and block the merge if possible).
I can't imagine I'm the only one trying to achieve this, so I am probably looking in the wrong direction. The 'best' solution I found is to somehow manually parse the build output and generate a JUnit report.
How would I go about doing this without allowing the build job to fail, since I would like the job to fail when compiler errors occur.
Update
For anyone stumbling across this question later, and in lieu of a best practice, this is how I solved it:
stages:
- build
- check-warnings
shellinspector:
stage: build
script:
- cmake -Bcmake-build -S.
- make -C cmake-build > >(tee make.output) 2> >(tee make.error)
artifacts:
paths:
- make.output
- make.error
expire_in: 1 week
analyse build:
stage: check-warnings
script:
- "if [[ $(cat make.error | grep warning -i) ]]; then cat make.error; exit 1; fi"
allow_failure: true
This stores the build output errors in make.error in the first stage, the next stage then queries that file for warnings and fails that stage with allow_failure: true to create the passed with warning pipeline status I was looking for.
It seems that the solution to such need (e.g., see the issue "Add new CI state: has-warnings" https://gitlab.com/gitlab-org/gitlab-runner/issues/1224) has been to introduce the allow_failure option so that one job can be the compilation itself, which is not allowed to fail (if it does, then the pipeline fails) and another job can be the detection of such warnings which is allowed to fail (if one is found then the pipeline will not fail).
Also the possibility of defining warning regex in the .gitlab-ci.yml has been requested but it does not exist yet.
Related
I rewrite a program and just removed a lot of code, by just making it a comment. After doing that and adding some tests, it is impossible to run the program anymore.
when running go build it has no errors at all.
But when running go test i only become some weird output:
$ go test
2020/05/05 19:14:24 open : no such file or directory
exit status 1
FAIL fwew_lib 0.002s
This error occurs, before a single test is even run, so within the test framework itself.
Why is there is no file specified that is not found? Any idea, what caused this error and how to fix it?
This error also occurred on multiple machines with windows and linux. And with go 1.14.2 and go 1.13.7.
To get this error yourself:
Repo: https://github.com/knoxfighter/fwew/tree/library
Branch: library
Just download the branch and run go test
Your fork is missing this line from the parent
texts["dictionary"] = filepath.Join(texts["dataDir"], "dictionary.txt")
link
But your fork still has this line which depends on the one mentioned above
Version.DictBuild = SHA1Hash(texts["dictionary"])
link
And so the SHA1Hash "fatals" out since you're essentially passing it an empty string.
link
When using stack in a project with multiple cabal files, there seems to be a difference in verbosity when using a stack command on a single target vs multiple targets.
This seems to happen for all sorts of stack commands, so I'll just give a few examples.
With stack build sub-project-1, stack will show progress on each of the modules it compiles. But stack build sub-project-1 sub-project-2 or stack build will suddenly show only which target it is working on and not show any of the modules it is working on.
Another example I have found recently is in stack test. I wanted to get a full list of all the Tasty tests I have, so I ran stack test --test-arguments="-l". But all it printed out was:
sub-project-1-0.0.0.1: test (suite: run-tests, args: -l)
sub-project-2-0.0.0.1: test (suite: run-tests, args: -l)
Completed 2 action(s).
Log files have been written to: /projdir/.stack-work/logs/
Even if I manually specify the targets I want eg:stack test sub-project-1 sub-project-2 --test-arguments="-l", it gives me the same unhelpful output.
I have to run stack with exactly one target: stack test sub-project-1 --test-arguments="-l" to get any of the output I am looking for:
sub-project-1-0.0.0.1: test (suite: run-tests, args: -l)
all tests/tasty tests/this is a test
all tests/tasty tests/this is another test
Is there anything I can do to get stack to not squelch the output when running against more than one package? Stack verbosity levels don't seem to have anything to do with this. They seem to consider -v to mean "print out debugging statements"
Thanks to sjakobi for the suggestion.
Recent versions of stack have an option: --dump-logs
This option will show the output from each action stack takes on each target.
When trying to build a fiware/cygnus docker image from the source code, the last part of it, namely the building of the image from the jar with:
docker build -f ./docker/Dockerfile -t fiware/cygnus .
gives the following message in the last step (8) of the building process: "no source files were specified". At this point the building appears to be aborted.
The building was done according: https://github.com/telefonicaid/fiware-cygnus/tree/master/docker (source code from: https://github.com/telefonicaid/fiware-cygnus.git ), and basically amounts to first building the java archive (jar) from the provided source code, and subsequently building the docker image from the jar file.
1) What could be the reason for the message in step 8? Since, according to the documentation, no other steps were mentioned. Also, the "target" directory, which is specifically mentioned in the documentation, appears not to be made.
2) However, there does appear an image, but with no tags (cf the "-t fiware/cygnus" flag in the command mentioned above). Is this a result from the fact that the building was only done up to step 8, leaving an incomplete image?
Many thanks!
Step 8 is
Step 8 : ADD ./target/*.jar /tmp/
This means that probably you haven't had success building the jar.
Replicating the steps with the current HEAD 2a9c87fb7fd6156225e2eed7fbc9792f1d9c5dfe gave me some errors, attributed to the JAVA_HOME variable not properly set.
Please, implement the following changes in your Dockerfiles until we merge the into master:
https://github.com/telefonicaid/fiware-cygnus/pull/695/files
I am using travis-ci and biicode to build my project who is depending on boost log. But boost log times are longer than 10 min so I get this message:
No output has been received in the last 10 minutes, this potentially indicates a
stalled build or something wrong with the build itself.
The build has been terminated
The build is working correctly, it's just that boost log is really long to compile with limited resources (I tried to compile it on a VM with 1 CPU and 2GB of RAM and it took almost more than 15 min)
I know this is happening because there is not enough verbose going on so I tried the following flags:
>bii cpp:build -- VERBOSE=1
In the CMakeList.txt, set BII_BOOST_VERBOSE ON as mentionnened here
Set BOOST_LOG_COMPILE_FAST_ON as explained here
Using travis_wait
Actually travis_wait seems to be the correct solution but when I put it in my .travis.yml like this
script: travis_wait bii cpp:build
It does actually doesn't output logs like usually and just time out after 20 min. I don't think the actual building is taking place
What is the correct way to handle this problem?
This is a known issue, Boost.Log takes a long time to compile.
You can use travis_wait to call bii cpp:configure, but I'm with you, I need log feedback (No pun intended). However, I have tried that too and leaded to >50min build, which means travis aborts build on free accounts :( Of course my repo does not build Boost.Log only.
Just as a note, here's part of the settings.py file from the boost-biicode repo:
#Boost.Log takes so much time to compile, leads to timeouts on Travis CI
#It was tested on Windows and linux, works 'ok' (Be careful with linking settings)
if args.ci: del packages['examples/boost-log']
I'm currently working on a solution, launching asynchronous builds while printing progress. Check this issue. It will be ready for this week :)
To speed-up your build, try to play with BII_BOOST_BUILD_J variable to set the number of threads you want for building Boost components. Here's an example:
script:
- bii cpp:configure -DBII_BOOST_BUILD_J=4
Be careful, more threads means more RAM needed to compile at a time. Be sure you don't make the travis job VM go out of memory.
Question
The RUN_CLANG_STATIC_ANALYZER ("Run Static Analyzer") project setting has found important issues in our project. We have addressed them and we want to prevent future issues from creeping in.
We're trying to get clang analysis warnings to
be treated as errors to break our build. So far no success despite having -Werror ("Treat Warnings as Errors") enabled.
Example of Problem
The following analysis call generated within Xcode:
/Developer/usr/bin/clang -x objective-c [...] --analyze [...]/TroubledCode.m -o [...]/TroubledTarget.build/StaticAnalyzer/normal/i386/TroubledCode.plist
produces a static code analysis warning:
[...]/TroubledCode.m:38:34: warning: Potential leak of an object allocated on line 38 and stored into 'leakingManager'
Manager *leakingManager = [[Manager alloc] init];
^
1 warning generated.
but Xcode reports "Build Succeeded ... 1 analyzer result". The solution we're looking for would make the example above generate a "Build Failed".
Solution
I took Jim's advice and created a build script.
To avoid false alarms, I went through the trouble of making sure it ignores extraneous analysis residue. This solution should work when building from the Xcode IDE and when building your project using xcodebuild.
To turn Xcode 3 analysis warnings into build errors:
Double click the project or target in question.
Under the Build tab, check the box under Settings > Linking > Write Link Map File
That setting is also known as LD_GENERATE_MAP_FILE.
Under "Groups & Files" > "Targets", click the disclosure triangle of the target you'd like to add this feature to.
Right-click the "Link Binary With Libraries" phase.
select Add > New Build Phase > New Run Script Build Phase
optional: Rename the "Run Script" phase you just added to "Treat Clang Warnings as Errors".
Double-click the new script phase if it's not already open.
Copy the content below and paste it into the "Script" section.
error_count=0
##
function verify_clang_analysis_at_path()
{
local analysis_path=$1
local plist_tool=/usr/libexec/PlistBuddy
local diagnostics=$($plist_tool -c "print diagnostics" $analysis_path)
if [[ $diagnostics != $'Array {\n}' ]]
then
((error_count++))
fi
}
function verify_clang_analysis_for_object_file()
{
local object_file=$1
local analysis_directory=$TARGET_TEMP_DIR/StaticAnalyzer/$CURRENT_VARIANT/$CURRENT_ARCH
local analysis_path=$analysis_directory/${object_file%.*}.plist
# if this object file corresponds to a source file that clang analyzed...
if [ -e $analysis_path ]
then
verify_clang_analysis_at_path $analysis_path
fi
}
##
object_directory=$OBJECT_FILE_DIR-$CURRENT_VARIANT/$CURRENT_ARCH
object_path_pattern=${object_directory}'/\(.\)\+\.o$'
index_pattern='\[[[:space:]0-9]*\][[:space:]]'
object_paths=$(
grep $object_path_pattern $LD_MAP_FILE_PATH | sed s/$index_pattern//
)
##
for object_path in $object_paths
do
object_file=${object_path##*/}
verify_clang_analysis_for_object_file $object_file
done
if [ $error_count -gt 0 ]
then
echo "Clang static code analysis failed for" $error_count "source file(s)."
fi
exit $error_count
Update
Mike Vosseller has an upgraded version of this script for Xcode 5.
We've been planning on having a separate build step to run the analyzer and check the results. We'll fail the build on the build server that way. That won't help you locally, though.
Xcode has a "Treat warnings as errors" checkbox. If you can't find it, which has been said for some iPhone projects, just add "-Werror" to your WARNING_CFLAGS in the Build Settings for your target(s) in question.