Good news for GitLab users! We are happy to announce that now Scrutinizer also supports GitLab repositories - be that self-hosted on your own instance or on gitlab.com.
Like for GitHub and Bitbucket, each time you push a commit or create a merge request, an inspection will automatically be triggered and the status communicated back to GitLab.
To add a GitLab repository, simply select GitLab on the repository add page:
In our documentation, we have some more details about how to set-up your GitLab instance.
And as always - happy scrutinizing :)
Selenium is a great tool for running UI based tests. You can get automated browser tests up and running in a matter of hours. However, as easy as Selenium is to set up. Selenium tests can be unstable, sometimes they work and now and then they fail.
Understanding why a Selenium test failed can often be a painful and time-consuming process. We have created this feature to take the pain out, and drastically reduce the time you spend to figure the causes out.
For all of your test commands in the
tests section of your
we record any activity that occurs on the build machine’s display. If your test
fails, the recording is stored and you can use it for quickly debugging the
failure. Let’s take a look:
The display recording and the console output of the running task are displayed in sync. As the video is played, we re-play the output as it happened when your tests were running. So when you see an error on the display, you can see which step was executing on the command line and vice-versa.
Recordings are automatically enabled for all repositories, and even if you heavily use the UI, they cause virtually no overhead. We observed a maximum of 3% added CPU usage. If your task succeeds, the recording will be discarded. If it fails, we encode it at the end of your run so that you can view it in your browser.
While an inspection is running in SSH debug mode, you can now also view a live stream of the display without having to go through any complicated set-up directly in the browser. Checkout the new “Display” tab:
We think this will make Selenium tests a lot more enjoyable.
Let us know what you think! :)
We are happy to announce the availability of our new Chrome extension. It boosts productivity by allowing you to now view analysis result directly inside GitHub. You do not need to leave the page, but you can go through the issues just when you manually review the code:
The extension is still in beta as we add some more features. You can check out our documentation for the features that are already available.
Happy & productive scrutinizing!
Just a bit over a week ago, we released our new PHP security analysis; it checks your PHP projects for over 500 security vulnerabilities from categories such as XSS, different injection vulnerabilities, file inclusion, code execution and a lot more.
Yesterday, YOAST - a developer of several popular Wordpress plugins -, and others released several security updates that fix XSS vulnerabilities found by Scrutinizer. Since some of the potential attack vectors were found in several WordPress plugins, WordPress’s developer documentation was updated as part of the coordinate response, too. If you are using WordPress, make sure to upgrade your plugins to the latest versions.
Scrutinizer also found other vulnerabilities that are still being fixed at the moment. We will share more once the security releases have been made, and users have had a chance to upgrade.
Happy & Secure Coding! :)
Chances are you might have heard of sensational performance improvements in PHP’s package manager, composer, of 30-90% of original runtime by changing not even a single line of code.
I initially suggested this change to the composer team on December 1st, and after some positive reports, it made its way into the production version of composer soon after, and is since then available to all PHP users.
At Scrutinizer, we run a lot of CLI-based analysis tools, some of which are written in PHP, and some of these create a lot of objects f.e. during type-inference.
Very early in Scrutinizer’s development (maybe something like 1.5 years ago), we noticed that the analysis time of bigger packages was not increasing linearly, but rather expontentially. Of course, we used profilers like XHProf to track down the issue, but the results were inconclusive; time was spent randomly in different places.
After some research, we came to the conclusion that garbage collection might be responsible, and indeed after disabling it, the analysis of a bigger package like Symfony2 went down from over 50 minutes to less than 10 minutes (this was more than a year ago).
It was only until a few days ago, that we realized that composer did not contain this fix, and might benefit from this, too. When a performance improvement that Nils made had a significantly different impact depending on how many dependencies someone had. The rest of the story is history now :)
Chances are most likely, no. This particular bad behavior of PHP’s GC only manifests itself in long running CLI processes that create tens of thousands of objects. Web-requests are likely not affected.
If you profile your application, and time is randomly spent in different places from run to run. This is the usual pattern to look for. If you see this, only then try running with GC disabled.
There are also some initiatives now to provide better support for profilers to measure the time spent in GC which will make this even easier.
The short, and counter-intuitive answer is no. You will not see a change in your memory consumption.
First, the call to
gc_disable() does not turn off garbage collection entirely,
it just disables one particular GC strategy that cleans up circular references.
Second, if you see this particular performance degradation, the garbage collection is not working anyway. It basically tries to clean-up your objects, only to recognize that it cannot clean them up, and it does that frequently. This is where the time is lost and the huge improvement is coming from when disabling it.
For a detailed explanation of the different GC strategies in PHP, check out this blog post from Anthony.
Like said above, this is mostly something that affects CLI tools. One prime candidate
that comes to mind is
phpunit. If you have a big test-suite, try running it
with GC disabled:
php -d zend.enable_gc=0 vendor/bin/phpunit