Okay, hello, I'm Gabor Keremann from Allotopia at BMW and I would like to talk about how
we do crash testing in the backyard.
So let's start.
What is even this crash testing?
Crash testing is a QA subproject of TDF and it's run on the master branch around every
second week.
So what is this testing?
It's testing continuously opening files, saving them in different formats and reopening of
those saved files.
And make sure that crashes during this workflow don't happen because that's kind of bad for
user perspective.
And usually this process sends a resulting mail to the developer's list and interested
parties like mostly Kaolan fix those crashes and that's good on master branch.
But what if the long-term support branches which we maintain for customers introduce
such errors that would be kind of bad for customers.
So we wanted to avoid that in the longer run.
Okay, so what are the prerequisites for this work?
You need first some hardware, a beefy system with many CPU threats because there is a lot
of files to test and of course bunch of files, tens of thousands and this can be downloaded
using scripts in the core repository.
Then you need the crash testing scripts themselves.
You need to download them on the beefy system, configure them to build LibreOffice, run
them on the set of files you have just downloaded and also interpret the results.
So this is how the beefy system looks in real life.
It's nothing entirely in the backyard but on the couch, let's say.
It also needs some 40 CPUs or so and a lot of disk space as well.
Next, second step is downloading files.
First script is called like this in the core repository and this makes, it downloads user
made file attachments from public bug trackers such as TDF and Apache OpenOffice bugzilla,
Linux distribution bug trackers and office software bug trackers such as K-Office, Gnomeric
and Abii Word and it has some lovely or less lovely un-user friendly properties such as
you need to install some extra Python modules and set an environment variable to Taylor
for your hardware so that the download happens quite quickly and you need to run it from
the download target directory but that's all that gave it at this script.
Next, second script is a website scraper called like this.
It needs also some Python modules.
You can add the target directory as parameter and some Microsoft Office themed forums will
need registration before this can work on them and login data needs to be stored in
any format file.
Next, getting the crash testing scripts themselves.
It's not in the core repository but this other contrib dev tools repository and in the test
bugzilla files directory.
So how to make sense of that.
Configuring the environment is also very important and this is the most difficult part of this
talk so before you start running the scripts you need to configure the environment with
this config file.
It needs to be placed on that path.
There are some defaults in the dev tools repository but you should overwrite those.
The most important settings are this compiler, sorry, the compiler version GCC or clang works
the same in this regard but you just need to take care that the old version of Libre
Office you want to compile actually compiles with your compiler.
You need to set the parallelism, how many CPU threads you have, it's with workers environment
variable and the most important thing is the path for this script.
So we need the location of the files to test which were downloaded by the two slides ago
and after that you need to hard code the dev tools repository path with this TT path and
next is source there for the Libre Office core repository clone which you also need
to compile and you need a build directory where the output of the computation will go.
So in the build directory you need also place the autogen input file, it's also in the
dev tools repository.
And of course you don't want to send the casual email and upload the results to TDF site
because it's internal for the company so you need to set these two other tools variables.
Okay next it's easy, there is a crash test data variable for the downloaded files, you
need to copy your files there and execute the commands shell script which will do all
the heavy lifting and basically that's all.
These arts will be in the crash test data directory on the logs and the mail txt file
will be the summary of the run.
Next step is finding what went wrong and fix the actual crashes which is just casual back
porting bug fixing.
So what are gains of upstream from this work, there are some, I made these scripts a lot
more configurable so you can set them up more easily for other companies.
For that it was only able to run on the TDF server and it was kind of a pain to transplant
it to another machine.
Also a little bit of performance gain, there was a bottleneck and the upstream also can
run this work more quickly.
And that's all, thanks for the attention.