Hi everyone, it’s been a while without writing something. Not that I don’t want to, but this 2020 has been very crazy.
Many changes, including the goals in LabVIEW IDE development with dropping the development of NXG (see here).
But, this post is about the latest update (a bit late) in Gitlab 13.6, where introduced a new field in Gitlab Code Quality Report (Code Climate).
This update included many other features, you may want to read all of them at here, including one that can change the default/protected branch name at the instance/group/project level.
The Update
Well, my posts are already getting old, but it is never too late to update them. If you want to check at this old post, the link is here.
So, in the past few days I refactored my code for generating the report including this new field. I took the opportunity to write some unit tests (yey), and I also let it ready to integrate in another code that I am using for running a custom LabVIEW CLI Operation, you can see it here.
Changes
The main change in the Gitlab Parser is the inclusion of a new field called severity.
[
{
"description": "'unused' is assigned a value but never used.",
"fingerprint": "7815696ecbf1c96e6894b779456d330e",
"severity": "minor",
"location": {
"path": "lib/index.js",
"lines": {
"begin": 42
}
}
}
]
As stated in the specification page, the severity can be info, minor, major, critical or blocker. If you want to see the specifications, you can click here.
The question was, how can I match this new field with the VI Analyzer Results that does not have this severity property?
Adapting
The solution is adapting. There is a field in VI Analyzer that categorizes the test in rank. So tests can be classified in Low, Normal and High.
So, looking at the icon we already have a clue which one will be the info, the other classifications we will have to use our logic and reason.
So, the relationship is:
- info – low rank test
- minor – normal rank tests
- major – high rank tests
- critical – high ranks test which exceeded the allowed maximum failures
- blocker – no ideas for this one yet, I will ignore it
Test Verdict
After setting that, you will have to decide when the failures will cause your CI job to fail. And for that, I may have found a solution in the VI Analyzer manual.
The manual is very clear:
High-ranking tests involve issues that have a significant impact on VI performance or may cause unintended bugs in VI execution. Low-ranking tests involve minor style or cosmetic issues that do not significantly affect VI performance.
So, at, my LabVIEWCLI custom operation I am filtering to output “succeeded” only when there aren’t any major or critical severity tests results.
Aside that, you will need to spend some time to set the appropriate rank in your VI Analyzer Tests Configuration, based on your experience, or just leaving as it is, trusting the creators of the test or the NI VI Analyzer TK developers.
Gitlab Code
As always you can check out the code from my Gitlab Page.
https://gitlab.com/felipe_public/gitlab-tools-labview/gitlab-code-quality-labview
If you find any bugs or suggestions, the code is open source, you can open an issue or suggest some modifications.
Felipe's Thoughts 