May 24, 2017 linglong meng linglongscru

Support for GitLab Repositories

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:

https://d2hs8c246tsqgl.cloudfront.net/blog/introducing-support-for-self-hosted-gitlab-instances-and-gitlab-com/5429593d745acdb0fbbc690adc0d617f-1.png

In our documentation, we have some more details about how to set-up your GitLab instance.

And as always - happy scrutinizing :)


February 8, 2017 Hans-Peter Martini h2p3m

Simplifying Debugging of UI Tests

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.

Smart Display Recordings

For all of your test commands in the tests section of your .scrutinizer.yml, 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:

https://d2hs8c246tsqgl.cloudfront.net/blog/simple-debugging-of-ui-tests/65b71e0d11e9afe7021c74d3f7b3c4db-1b.gif

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.

Live Display Stream

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:

https://d2hs8c246tsqgl.cloudfront.net/blog/simple-debugging-of-ui-tests/73466d029c7ecd280b9df67b3724e414-2a.png

We think this will make Selenium tests a lot more enjoyable.

Let us know what you think! :)


March 9, 2016 Johannes Schmitt schmittjoh

View Analysis Results inside GitHub

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:

Inline Issue on GitHub

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!


April 21, 2015 Johannes Schmitt schmittjoh

December 4, 2014 Johannes Schmitt schmittjoh

Composer, the GC performance improvement, and who else might be affected

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.

How was the issue found?

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 :)

Is your app affected, too?

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.

Is memory consumption increased when disabling GC?

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.

Which other tools might be affected?

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