I'm not a front-end developer, but I need to get a sonarqube scan working with unit test coverage. All of this WAS working, but we had a big SonarQube version upgrade (6.x to 7.9.1), and it was broken for a while, and now I'm trying to get it working again.
As this used to work, what we have must be close, but there's some detail that isn't quite right.
When the build runs, it runs the unit tests and appears to generate coverage data, and the call to "sonar-scanner" sends the path to the lcov.info file. In the SonarQube project, it has a large number of "lines to cover", but with the same number of uncovered lines. I also note that it doesn't have a "Unit Tests" section in the overview.
In the build output, I see quite a few lines like this:
DEBUG: 'src/api/Api.spec.tsx' indexed as test with language 'ts'
But as noted above, the SonarQube project doesn't appear to think there are any unit tests.
As part of the build script, at the end of the tests run, I ran "ls -lt coverage" to see what was generated, and it showed this:
total 6264
-rw-r--r-- 1 81050 20059 1229978 Jan 4 19:12 clover.xml
-rw-r--r-- 1 81050 20059 720443 Jan 4 19:12 lcov.info
drwxr-xr-x 6 81050 20059 4096 Jan 4 19:12 lcov-report
-rw-r--r-- 1 81050 20059 4455341 Jan 4 19:12 coverage-final.json
I see references in this file to "Api.tsx" (and many others), but I don't see a reference to "Api.spec.tsx", but I have no idea whether I should expect any.
I've looked at the jest configuration in "package.json", but I don't see any obvious problems.
What else can I show here that might provide a clue?
Update:
Here is the resulting sonar-scanner command line, with some elisions:
sonar-scanner -Dsonar.typescript.node=/opt/app/bin/node -Dsonar.nodejs.executable=/opt/app/bin/node -Dsonar.host.url=http://... -Dsonar.login=... -Dsonar.password= -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info -Dsonar.typescript.lcov.reportPaths=coverage/lcov.info -Dsonar.branch.name= -Dsonar.language=js -Dsonar.projectKey=... -Dsonar.projectName=... '-Dsonar.exclusions=**/*.scss.d.ts, **/*.scss, **/*Props.ts, **/*State.ts, **/*index.ts' '-Dsonar.coverage.exclusions=**/*.spec.tsx, **/*.spec.ts, **/*.scss.d.ts, **/*.css.d.ts, **/*.scss' -Dsonar.projectVersion=1.0.0 '-Dsonar.sources=src/components/,src/api/,src/models/mappers/, src/utils/' '-Dsonar.lang.patterns.js=*/.ts,*/.tsx' -Dsonar.js.file.suffixes=.ts,.tsx -Dsonar.sourceEncoding=UTF-8 -Dsonar.tests=src '-Dsonar.test.inclusions=**/*.spec.tsx' -Dsonar.typescript.tslintconfigpath=tslint.json -Dsonar.log.level=DEBUG -Dsonar.verbose=true '-Dsonar.exec.maxBuffer=1024 * 1024'
I'd forgotten I'd asked this question. I had to go back to the code and history to see if I could remember what I did to fix it. I assume it would be what I discovered here:
https://community.sonarsource.com/t/sensor-sonarts-coverage-fails-to-match-path-with-symbolic-link/14601
In short, if file paths in the generated files include symbolic link entries, there was a bug in SonarTS that made it fail to follow symbolic links. What I did to fix this particular problem was examine my generated files to understand the pattern of what symbolic links were being utilized, and I wrote a script to post-process the lcov.info and test-report.xml file to replace paths to symbolic links with the absolute path to the non-symlinked file.
Related
I’m trying to run the following command to generate grpc files:
protoc --proto_path=$PROTO_PATH --plugin=protoc-gen-grpc=$PLUGIN_GRPC --grpc_out=$OUT/grpc $PROTO_FILES
This results in the following error:
/Users/MYUSERNAME/Downloads/protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--grpc_out: protoc-gen-grpc: Plugin failed with status code 1.
I made sure the file from the error message is located at that path and has also the correct permissions.
-rwxrwxrwx# 1 MYUSERNAME staff 6334176 10 Aug 00:03 protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe
I also tried running the command as sudo.
Generating java or kotlin files with --java_out=$OUT/java --kotlin_out=$OUT/kotlin
works perfectly fine, so the problem is --grpc_out=$OUT/grpc
I also downloaded multiple versions of the protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe file but it always results in the same error. I also tried replacing all path variables (e.g. $PROTO_PATH) with their corresponding values, without any effect. I’m using MacBook with M1Pro chip.
The problem is that M1 Macs aren't supported. They have copied over the osx-x86_64 binary and renamed it for osx-aarch_64 as a workaround to make it easier to run with Rosetta. See here for where that change was made and here for the full conversation about supporting M1 Macs.
I have a Windows 10 laptop where no TeX distribution was ever installed before (double-checked for config directories, files, and environment variables).
Wanting to install TeX Live 2021, I followed the full installation guide and also read the Windows-specific warnings. I've now tried several times, following different installation procedures - cleaning up everything (deleting base & user directories, environment variables, etc) before each time - but still don't manage to get a working installation. Before I report a bug at tex-live#tug, I wanted to ask for advice here, in case I'm doing something wrong. Here is what I did, step by step, and the problems I encountered in the process.
1. First I tried running the recommended online installer install-tl-windows.exe. It never got past the screen that tries to contact or load from a repository, even after a 30-min wait. Tried a dozen times, choosing different mirrors nearby and far away. No luck.
2. Then I downloaded and unpacked the install-tl.zip and run install-tl-windows.bat therein. This time the main installation window appeared. I left all default paths and environment variables (note that I do have write access to C:); in the selection scheme I unselected all languages except US & UK English, unselected XeTeX, LuaTeX, ConTeXt; also unselected TeXworks (I use Emacs), and clicked Install. After one to three hours (depending on the mirror I chose), the installation was complete.
I tried compiling a minimal latex document (see below), and got an error similar to the one in this old question:
I can't find the format file `pdflatex.fmt'
Following the advice in the answers to that question and similar questions elsewhere online such as this, I tried running texhash and fmtutil-sys --all. The latter gave the error
no appropriate script or programme found fmtutil.
for which there are also many posts online.
2a. Not understanding what the problem could be, I re-tried with all possible combinations of the following three options: (a) choosing different mirrors; (b) leaving the full selection of packages (ie without unselecting some languages, LuaTeX etc); (c) redoing the procedure by choosing "Run as Administrator". No luck.
3. At this point I tried downloading the ISO file with the full installation. Mounted the image and run install-tl-windows.bat (as normal user, as recommended; I repeat that I do have write access to C:). Everything proceeded as in step 2. above. At the end of the installation I tried running pdflatex on the minimal latex document. New error this time:
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021/W32TeX) (preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./minimal-template.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-02-18>
! LaTeX Error: File `article.cls' not found.
Very strange. A file search revealed that article.cls is in the TeXLive file system; but kpathsea did not see it indeed.
4. At this point I opened the TeX Live Shell from the Start Menu; selected a CTAN mirror; updated the TL Manager which was not up to date; updated all packages; run Regenerate filename database; and run Regenerate formats. With the latter I got this error:
tex live shell:
mtutil [INFO]: total formats: 59
fmtutil [INFO]: exiting with status 53
C:\texlive\2021\bin\win32\runscript.tlu:915: command failed with exit code 53:
perl.exe c:\texlive\2021\texmf-dist\scripts\texlive\fmtutil.pl --sys --all
Here is a snip from the full set of errors appearing in the "Other" tab (I'm replacing my user directory with asterisks for privacy; note that I do have write access to these directories):
start load https://www.nic.funet.fi/pub/TeX/CTAN/systems/texlive/tlnet
finish load https://www.nic.funet.fi/pub/TeX/CTAN/systems/texlive/tlnet
start load http://contrib.texlive.info/current
finish load http://contrib.texlive.info/current
running mktexlsr ...
done running mktexlsr.
running mtxrun --generate ...
done running mtxrun --generate.
running updmap-sys ...
done running updmap-sys.
regenerating fmtutil.cnf in C:/texlive/2021/texmf-dist
running fmtutil-sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX ...
tlmgr.pl: fmtutil-sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX failed (status 255), output:
Unknown option: status-file
Try "fmtutil --help" for more information.
C:\texlive\2021\bin\win32\runscript.tlu:915: command failed with exit code 255:
perl.exe c:\texlive\2021\texmf-dist\scripts\texlive\fmtutil.pl --sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX
running fmtutil-sys --byengine luajithbtex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX ...
I tried to continue anyway with Regenerate fontmaps, and then tried again pdflatex on the minimal document. New error:
This is pdfTeX, Version 3.141592653-2.6-1.40.23 (TeX Live 2021/W32TeX) (preloaded format=pdflatex)
restricted \write18 enabled.
---! c:/texlive/2021/texmf-var/web2c/pdftex/pdflatex.fmt made by different executable version
(Fatal format file error; I'm stymied)
5. I tried again steps 3. and 4., but with "Run as Administrator". Same errors.
OK at this point I give up and really don't know what to do. Am I doing something wrong? For the moment I have to concur with this post: installation of TeX Live 2021 is an utter failure.
Here is the minimal latex file I used for testing (copy & paste):
\documentclass{article}
\begin{document}
test
\section{Section}
test
\end{document}
Found, that the download is not working because the system path to "cmd.exe" is not found. Therefore: open a cmd window and add the system path prior to starting the .bat file (set PATH=%PATH%;C:\Windows\system32)
I have been following this guide from the gentto wiki to install Gentoo. I have hit a bit of a roadblock though which looks reasonably simple but I am having trouble figuring it out.
On this page: https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot#test_secure_boot
In the Testing Secure Boot with a Signed Kernel section whilst executing the buildkernel command I get the following error:
* Updating old config using make olddefconfig
make: *** No rule to make target 'olddefconfig'. Stop.
* buildkernel: Error: Caught signal - exiting
I don't seem to have an olddefconfig at all and even if I did have one I am not entirely sure what rule should be added to the make file.
I have read the man page for the buildkernel command and gone over this description here but sadly I have still not managed to fix the issue.
Does anyone know how to rectify this error?
So I now have an answer for this. It sometimes happens when the kernel sources have been updated to a new version, but the symbolic link /usr/src/linux hasn't been updated to
match. Gentoo leaves a partially populated kernel source tree in
/usr/src/linux--genoo even when an old kernel source version is
unmerged, and if the symbolic link /usr/src/linux still points to this.
if you run:
eselect kernel list
and it produces something like:
Available kernel symlink targets:
[1] linux-4.14.63-gentoo-r1
and
ls -l /usr/src/
produces something along the lines of:
total 8
lrwxrwxrwx 1 root root 20 Aug 18 00:33 linux -> linux-4.14.61-gentoo
drwxr-xr-x 23 root root 4096 Aug 18 02:38 linux-4.14.61-gentoo
drwxr-xr-x 25 root root 4096 Aug 18 02:33 linux-4.14.63-gentoo-r1
Running the following command will update the symbolic link and let you get on with things.
eselect kernel set 1
I emailed the author of the guide to get this information so credit goes to her. I am leaving this here in case anyone else runs into this problem in future.
I (and my colleague) are having this problem with 32-bit applications on a 64-bit Windows 7 OS. We have also found the same problems when we invoke a 64-bit application and pass a path as described below as a parameter in cmd.exe.
Given the path "C:\dir1\dir2\file1.txt", we have some 32-bit applications that don't appear to be able to consistently resolve that path and find the file if there is a hidden file of a particular naming structure causing it to lose it's way.
For example, given the directory/file structure:
\dir1
\dir2
\file1.txt
\.dir2Blah
Of importance is that the "hidden" file's name starts with the same characters as those which indicate a directory at that same level of the hierarchy. What comes after that in the hidden file's name is irrelevant. It could be called ".dir2Whatever".
The problem is that more often than not (but not consistently always) some 32-bit applications we use can't find the file1.txt file. We're told it can't be found or it doesn't exist, etc. in the application. Using Process Monitor, we found the reason appears to be that while the path being asked for is C:\dir1\dir2\file1.txt, the path being evaluated by the the Windows system is C:\dir1\.dir2Blah\file1.txt.
We have found that some 32-bit applications appear to be able to work fine with those (what I would call) erroneous paths and successfully find the files in question but others do not.
As I said above, we have also found we can reproduce the problem with 64-bit applications if we try to open the file through a cmd.exe prompt; for example, "textpad.exe \dir1\dir2\file1.txt".
We've "googled" this problem for 2 days because we're completely stumped and cannot believe that no one else has ever encountered this if it's so "easy" to reproduce. My colleague and I are both able to cause the failure; not consistently, but file access will fail more than half the time when we set up the structure I described.
I've included a picture of Process Monitor showing this failure in two applications but succeeding in a third...here.
Can anyone tell me what is going on? First, why is it changing the path to use that hidden file rather than the directory name provided? And, more importantly, how can we make it stop ;-)?
Cheers,
jtm
Added later:
Here's the "dir /x" output for a directory where I'm having this problem.
24/05/2017 12:17 PM <DIR> .
24/05/2017 12:17 PM <DIR> ..
24/05/2017 12:17 PM 12 BLAHTS~1 .blahtst
23/05/2017 03:06 PM 104 JSHINT~1 .jshintrc
24/05/2017 12:16 PM <DIR> blah
24/05/2017 12:16 PM 0 blank.txt
24/05/2017 12:15 PM 6,624 INDEX~1.HTM index.html
24/05/2017 10:48 AM <DIR> js
It also indicates how we stumbled on the problem. I have an html file that is trying to load a JavaScript file under the /js directory, but there is also a .jshintrc file at the same level and my old Apache server can't find the files to serve them. If I remove the .jshintrc file, I can get around this, but this project isn't one I created and I'm leery of just removing things willy nilly.
I had some iOS projects in my macbook,one day I copied them to my pc which is based on windows system, then some day I copied them back to my macbook and I found the projects can not run.
I Opened one of the projects with Xcode, it says "builde successfully",but the app can not be deployed on the iPhone Simulator even if the Simulator is running!?!?!?! Then I check the files using "ls -l" command and found that the difference between normal Xcode project files and the new created Xcode project files is just a symbol.
files with problem:
drwx------+ 49 dingvimer staff 1.6K
normal file：
drwx------# 60 dingvimer staff 2.0K
How can I change that '+' symbol to '#' and get the project run normally?
I will appreciate your kindness of helping me to figure it out (^-^).
You can use ls -l# to see extended attributes. It will show you something like:
drwxr-xr-x# 5 cody staff 170 Mar 30 08:46 test.xcodeproj
LastUpgradeCheck 4
LastUpgradeCheck - is the name of attribute (sometimes there can be something like com.apple.blablabla) and 4 - is the value.
Use xattr command to set/delete extended attributes. See man xattr (its quite short and there are some examples).
Note, that you'll probably need to fix whole project directory.