Welcome everybody to today's HPC Cafe.

The title is How to on using the CX services based on the errors of eGitLab instances with

the help of the NHR FAU systems.

So the idea is to run the tests and so on on our HPC infrastructure.

This is basically the section from the FAQ corner that Jörg mentioned.

So these are the four main continuous or CX words you will find in the wild.

Continuous integration is basically download everything, build the dependencies, build

your code and run some tests.

But it's more focused on building it, less on the testing side.

For testing we have continuous testing, which is continuous integration with tests.

Continuous benchmarking is continuous integration, then doing some testing and in the end doing

some benchmarking.

So get real performance numbers of the code and to see whether you had introduced some

degradations by your code.

So if you add something new to your code and you run it there, you can see directly whether

it's working or not.

You still have better, the same performance, better performance, worse performance, so

on.

And the last one is continuous deployment.

Basically when you did all your testing, you set up some kind of package and push the package

to some index like PyPy or install it on a specific system, like add a new module to

our module system, things like that.

That's all continuous deployment.

So this is a recap from a previous talk we did in the HPC Cafe about Git.

I just copied out the YCX slide.

So why do we need that?

If you're building bigger software projects with a lot of backends that are optimized

for different architectures, it's tedious to test them by hand.

So CX is basically a tool to compile it on different machines, to test it on different

machines, and to test different outcome of specific stuff.

Unit tests, are we producing the correct results?

This is very important.

So if you're setting up, building some kind of software, please start writing unit tests

directly at the beginning.

This helps in the whole development process when you have tests already at hand.

Coverage is if you write code, is it used at all in one of the tests or is it not used?

So if you have some if construct added to your code, if this branch is never used, then

the test doesn't work for you.

Linting is like getting some well-written code in the end.

So it's formatting the code or showing you where you have formatting problems in your

code and deploying to production.

It's basically free, so it comes with most development platforms, GitHub has CX, GitLab

has CX, but also Bitbucket and all the other vendors on the market.

It helps you to find bugs earlier.

I had that case recently that one of my dependency libraries changed the API.

And since I'm doing automatic testing, as soon as our admins installed the new version

of this dependency, the CI wrote me a mail that this one doesn't work anymore.

So I directly find the bug.

It encourages the test-driven development.

That's basically the unit tests part.