schmittjoh
Scrutinizer has already supported tracking changes to your classes, methods and functions to measure the stability of your code. So far, these measures were computed on a per-inspection basis. This algorithm has now been revised to compute them on a per-commit basis.
This provides even more insights as it allows us to determine what kind of change a commit makes. Currently, we label commits as bug fixes and feature additions by inspecting the commit title with the following regular expressions.
You can adapt these patterns to your own workflow via the new changetracking setting in your configuration:
# .scrutinizer.yml
changetracking:
bug_patterns: ["\bfix(?:es|ed)?\b"]
feature_patterns: ["\badd(?:s|ed)?\b", "\bimplement(?:s|ed)?\b"]
We display the data in all code views and they will also be used in the upcoming revision to the code rating algorithm.
I would also like to take this opportunity to thank all our early customers and all our open-source users for their continued support and feedback in building this product. Keep them coming! :)
Last but not least, enjoy the holidays with your family and a merry Christmas!
schmittjoh
Scrutinizer has offered filtering false-positives since the very beginning. So far, you could only ignore a single instance of an issue; now, it is also possible to ignore all identical issues, or even just similar issues. This is especially useful if a specific analysis does not make sense for your project and does not require you to dig into the configuration:
Advanced issue filters work for issues from all supported analysis tools. Scrutinizer will automatically learn which parts of an issue message are dynamic and adjust the filterable parameters accordingly.
So far, our algorithm has mostly relied on Git for tracking issues. This works fine as long as diffs are relatively small and the line, which an issue is associated with, is not changed (even if it’s just a whitespace change or moving a brace around).
We now switched this to a fuzzy matching algorithm which is immune to such changes and can track issues more reliably. In one of your next inspections, you might see a message like “12 issues introduced and 12 issues fixed”. This is caused by the migration to the new algorithm, and should occur only once.
Happy inspecting! :)
schmittjoh
So far, Scrutinizer has heavily relied upon inspecting single pushes, or pull requests. This is ideal for providing fast feedback and allowing you to fix small issues right away.
For more architectural changes and also for project managers however, a longer perspective is necessary. To address this need, we are now introducing our first version of weekly development reports. The idea is to highlight the key points in development and trends of important metrics. Let’s take a look:
All reports are generated on Monday around 8am UTC, you can change this to any other time in your repository settings though.
Development reports are also a nice way to stay up to date with open-source projects as they contain the development highlights of the week. For any open-source project that is on Scrutinizer, you can subscribe to its weekly reports.
Happy developing :)
schmittjoh
In this post, I want to talk about a few UI upgrades that were made recently to accomodate for some newly added features and improve the overall usability of Scrutinizer.
Instead of the long worded rating classes like critical, very good, etc., we now use the letter system A-D and F. These take less space in the UI while communicating the same information and are simply much more enjoyable to read. If you don’t know about our rating system yet, I recommend to check out this blog post.
The complete mapping is as follows:
| Before | After |
|---|---|
| very good | A |
| good | B |
| satisfactory | C |
| pass | D |
| critical | F |
Alright, now on to the real features. First, the activity feeds now contain a lot more information and have less noice. Let’s take a look:
For each inspection, the most prominent changes are displayed directly in your activity stream and are not tucked away in the inspection’s pages anymore.
Second, the metrics view on the code structure pages has been upgraded. We already chose the most relevant metrics for you, now these are categorized and we also add visual cues as to which metrics require your attention:
Scrutinizer has gone from a spare time project to a real company with actual customers. It currently runs about 1000 inspections per day on over 1500 active repositories as of this writing, and growth is continuily increasing. This equals a data amount of about 2 GB per day which is generated, filtered and processed.
If this is the first time, you have read about Scrutinizer, or you haven’t been on our page for a while, check out our new Features page. There are also some interesting things in the pipeline like development reports which we will share over the coming weeks.
For now have a great weekend, and enjoy the rest of your day!
schmittjoh
So far, Scrutinizer has mostly passed through configuration options to the underlying analysis tools unchanged. With the introduction of the new build config editor, this now gets a lot easier:
Instead of having to create XML files and wading through the different documentations, you can now simply choose the rules that make sense for your project and Scrutinizer will take care of generating the necessary files for you:
