I am trying to get gitlab code coverage parsing working. The server is a local instance of Gitlab 10.4.1-ee. The code coverage tool is lcov via a slightly modified version of this cmake file.
I've entered the regex into the CI Settings as well as in the gitlab ci file to no avail. From what I understand the code coverage will not even attempt to parse if this is not supplied. It did work on one job (out of hundreds) and never again (not sure why). I have supplied both the output and the regex as inputs into http://rubular.com and it seems to parse correctly. I've also fooled around with various iterations of including the single quotes or not or the slashes or not in the regex also to no avail. I can't see where we can get any debugging output or something to show that this step is actually performed.
The project's CI/CD Settings > Test coverage parsing entry:
\bOverall\D+(\d+[.]\d\%)
The job's relevant .gitlab-ci.yml
coverage:
stage: build
image: <redacted>:stable
script:
- mkdir build
- cd build
- cmake -DCMAKE_BUILD_TYPE=Debug .. && make coverage
coverage: '/(?m)\bOverall\D+(\d+[.]\d\%)/'
artifacts:
paths:
- build/coverage/
The job's relevant output:
Overall coverage rate:
lines......: 95.2% (749 of 787 lines)
functions..: 96.5% (110 of 114 functions)
Open ./coverage/index.html in your browser to view the coverage report.
[100%] Built target coverage
Uploading artifacts...
build/coverage/: found 63 matching files
Uploading artifacts to coordinator... ok id=20671 responseStatus=201 Created token=kRnB--qX
Job succeeded
Turns out gitlab's coverage parser is not multi-line. The following regex ended up working lines[\.]+\: (\d+\.\d+)\%. My ci file coverage line ended up being:
coverage: '/lines[\.]+\: (\d+\.\d+)\%/'
Related
I'm trying to configure a GitHub action:
My action contains the job for running the unit test by collecting code coverage. As I see in the log:
Test Run Successful.
Total tests: 336
Passed: 336
Total time: 14.0930 Seconds
Calculating coverage result...
Generating report 'TestResults/coverage.netcoreapp2.1.info'
Nonetheless, after these lines log contains an error message:
/home/runner/.nuget/packages/coverlet.msbuild/2.9.0/build/coverlet.msbuild.targets(31,5): error : Module test path not found [/home/runner/work/ObservableComputations/ObservableComputations/src/ObservableComputations.Test/ObservableComputations.Test.csproj]
The job is failed.
I tried to run
dotnet test --no-build --filter Name~Casting --verbosity normal /p:CollectCoverage=true /p:CoverletOutput=TestResults/ /p:CoverletOutputFormat=lcov
at my local machine (MS Windows) and didn't get this error.
Any help is greatly appreciated.
The reason was in -no-build parameter for dotnet test. It seems coverage collecting requires dotnet test to build itself.
I have a .NET Framework project that is being built on a self hosted Windows build agent.
There is a step to run tests, and that step needs to provide code coverage reports and stats.
When i try using "dotnet test" the step runs and the tests complete, the .coverage files are also generated. When i check the build summary after it's complete i see the standard test results and report, and also the code coverage tab. The code coverage tab has a download link to get the file. There is no code coverage report. There is also a link to "Setup Code Coverage" on the initial build summary screen.
Why is there no code coverage report? and why is the "Setup Code Coverage" link still visible?
This is incredibly frustrating! I must be missing something incredibly obvious, but the docs suggest what i have done is correct.
Using VSTest task rather that dotnet tests results in the same outcome, but runs far slower.
displayName: dotnet test
inputs:
command: test
arguments: '--configuration $(BuildConfiguration) --collect:"Code Coverage"'
workingDirectory: '$(Build.SourcesDirectory)\src'```
I eventually achieved this by using Hugh Lin's answer for help and modifying for my own purposes.
We have Coverlet as a reference in the project, and ReportGenerator installed into Azure DevOps, so that made this a little easier.
I found that we had an issue with a SOAP API reference that was causing the huge performance issues with generating a report. Once I filtered that out with a "classfilter"the process became more manageable. I also found that without the "disable.coverage.autogenerate" variable the "PublishCodeCoverageResults" task will take forever and likely fail as it tries to do the "ReportGenerator" step itself by without the "classfilters". It does this because the "ReportGenerator" is built into the "PublishCodeCoverageResults" step now, but due to having no filters it doesn't work for this scenario.
This is running against a .NET Framework project so there were a few adjustments to the projects needed to ensure "dotnet test" works successfully.
variables:
disable.coverage.autogenerate: 'true'
- task: DotNetCoreCLI#2
displayName: dotnet test
inputs:
command: test
publishTestResults: true
arguments: '/p:CollectCoverage=true /p:CoverletOutputFormat=cobertura --no-restore'
workingDirectory: '$(Build.SourcesDirectory)\src'
configuration: "$(buildConfiguration)"
- task: reportgenerator#4
inputs:
reports: '$(Build.SourcesDirectory)\src\*.UnitTests\coverage.cobertura.xml'
targetdir: '$(Common.TestResultsDirectory)/CoverageReport/'
classfilters: '-NAMESPACE*'
- task: PublishCodeCoverageResults#1
inputs:
codeCoverageTool: 'Cobertura'
summaryFileLocation: '$(Build.SourcesDirectory)\src\*.UnitTests\coverage.cobertura.xml'
reportDirectory: '$(Common.TestResultsDirectory)/CoverageReport/'
By default, the code coverage for the dotnet test task is output to a .codecoverage file, which Azure DevOps does not know how to interpret and only provides as a downloadable file. Code coverage Tab only supports code coverage data in Jacoco or Cobertura formats. So the result of the *.coverage file can not be shown by tables and graphs.
If you want more detailed code coverage report, you need to use coverlet in .Net framework by install the tool during the pipeline and then generate the report. For example in PowerShell script:
dotnet tool install dotnet-reportgenerator --tool-path . --version 4.0.12
dotnet tool install coverlet.console --tool-path . --version 1.4.1
mkdir .\reports
$unitTestFile = gci -Recurse | ?{ $_.FullName -like "*bin\*test*.dll" }
$coverlet = "$pwd\coverlet.exe"
& $coverlet $unitTestFile.FullName --target "dotnet" --targetargs "vstest $($unitTestFile.FullName) --logger:trx" --format "cobertura"
gci -Recurse |
?{ $_.Name -eq "coverage.cobertura.xml"} |
%{ &"$pwd\reportgenerator.exe" "-reports:$($_.FullName)" "-targetdir:reports" "-reportstypes:HTMLInline;HTMLChart" }
Then add Publish code coverage task:
For details, you can refer to the case mentioned in the comment and this ticket.
I am writing Dockerfile and using multi-stage build concept to add layers.
One of the FROM layer is docker-sonarqube-scanner that pushes coverage reports to sonar server.
Dockerfile execution fails if this layer fails.
I would want this layer to be fail safe, that said, if there is no coverage report or dir exist, sonarqube should fail silently and Image building process should continue.
FROM hub.docker.com/st/docker-sonarqube-scanner:${scannerVersion} as sonar
ARG sonarProjKey
ARG sonarOpts
COPY --from=test /root/app /root/app
WORKDIR /root/app
RUN sonar-scanner --debug -Dsonar.projectKey=${sonarProjKey} ${sonarOpts}```
Where, sonarProjKey is name of project and sonarOpts is sonar options
If above layer fails, image building should continue.
I found a simple fix. Use semi-colons as instruction conjunctions and append RUN command with true, like this:
RUN sonar-scanner --debug -Dsonar.projectKey=${sonarProjKey} ${sonarOpts} ; true
I am getting error while trying to build a java project in TeamCity. The same project builds and excecutes well on my local. I recently pushed changes to this project on GitLab. This is my first time working with GitLab and TeamCity together. Other projects have no issues during build. I am unable to understand what is causing this error:
[15:58:54][Step 1/1] compile.earCommons (4s)
[15:58:54][compile.earCommons] echo
[15:58:54][compile.earCommons] echo
[15:58:54][compile.earCommons] wlcompile (4s)
[15:58:59][wlcompile]
com.bea.util.jam.internal.javadoc.JavadocClassloadingException: An error
has occurred while invoking javadoc to inspect your source
files. This may be due to the fact that $JAVA_HOME/lib/tools.jar does
not seem to be in your system classloader. One common case in which
this happens is when using the 'ant' tool, which uses a special
context classloader to load classes from tools.jar.
This situation elicits what is believed to a javadoc bug in the initial
release of JDK 1.6. Javadoc attempts to use its own context classloader
tools.jar but ignores one that may have already been set, which leads
to some classes being loaded into two different classloaders. The
telltale sign of this problem is a javadoc error message saying that
'languageVersion() must return LanguageVersion - you might see this
message in your process' output.
This will hopefully be fixed in a later release of JDK 1.6; if a new
version of 1.6 has become available, you might be able to solve this
by simply upgrading to the latest JDK.
Alternatively, you can work around it by simply including
$JAVA_HOME/lib/tools.jar in the java -classpath
parameter. If you are running ant, you will need to modify the standard
ant script to include tools.jar in the -classpath.
[15:58:59][Step 1/1] Process exited with code 1
[15:58:59][Step 1/1] Ant output
[15:59:10][Step 1/1] Process exited with code 1 (Step: Ant)
[15:58:59][Step 1/1] Step Ant failed
****Update****
Build Step: Ant
Step 1:
Runner type: Ant (Runner for Ant build.xml files)
Execute: If all previous steps finished successfully
build.xml file: \ant\build.xml
Working directory: same as checkout directory
Targets: none specified
Ant home path: C:\apache-ant-1.7.0
Additional Ant command line parameters: -lib c:\WebLogic\12.1.2\wlserver\server\lib\javaee.jar;c:\WebLogic\12.1.2\wlserver\server\lib\weblogic.jar;c:\WebLogic\12.1.2\wlserver\server\lib\webservices.jar
JDK home path: c:\Program Files\Java\jdk1.7.0_80
JVM command line parameters: not specified
Reduce test failure feedback time: OFF
Java code coverage: disabled
Docker Settings
Docker Image: unset
I'll appreciate any help in this regard.
I found there was character encoding issue with one of the files that prevented compiler from loading the java classes. Once that was fixed, the build worked fine.
I have a project which has two folders on same level
/home/ishan/my_repo/jenkins_test/business_logic
/home/ishan/my_repo/jenkins_test/test_cases
test_cases has two files test_fib and test_fact
when I run nosetests --exe at /home/ishan/my_repo/jenkins_test/ it runs correctly showing
....
----------------------------------------------------------------------
Ran 4 tests in 0.036s
OK
I am trying to run these test cases so, I created following script at /home/ishan/my_repo
#!/bin/bash
source /home/ishan/venv/bin/activate
nosetests --exe /home/ishan/sf_shared/my_repo/jenkin_test/
deactivate
When I run it using
source /home/ishan/my_repo/test_runner.sh it shows correct output.
So, I tried to put it in jenksins build step. So, I added the same line
source /home/ishan/my_repo/test_runner.sh in command section of Execute Shell in jenkins.
Now, when I trigger the build using build now it fails saying
Started by user anonymous
Building in workspace /var/lib/jenkins/workspace/jenkins_test
[jenkins_test] $ /bin/sh -xe /tmp/hudson5020664150857393715.sh
+ source /home/ishan/sf_shared/test_runner.sh
/tmp/hudson5020664150857393715.sh: 2: /tmp/hudson5020664150857393715.sh: source: not found
Build step 'Execute shell' marked build as failure
Finished: FAILURE
I think it doesn't even execute any test cases. It fails long before.
Can you suggest what am I doing wrong?
Maybe this will works:
/home/ishan/venv/bin/nosetests --exe /home/ishan/sf_shared/my_repo/jenkin_test/
Resolved it, issue was with the following line
source /home/ishan/venv/bin/activate
I replaced it source with standard . then it worked. So, my line became
. /home/ishan/venv/bin/activate