 Hello and welcome to our Romantic CI updates. And today we will talk about metrics builds. I will explain what are the metrics builds and we will see how to use the needs keyword with metrics builds added in GitLab 16.3 recently and a quick demo. Metrics builds allow users to define multiple build configurations within a single job. As you can see here in the right code example, you have a test job. And at the bottom you see the parallel metrics keyword that gets two arrays with parameters. And as a result, during runtime, the pipeline will look like this. This job will create four different test jobs with different parameters. That means that all of the inputs that they put here will become a CI CD environment variables that I will be able to use in the CI CD configuration. So imagine that you get is a requirement to test your application, to get a spreadsheet with metrics of 20 or 50 different platforms, environment, writing systems can live in different kind of hardware. And now you need to test all of this long list of metrics in your pipeline. So instead of writing so many different jobs we'll cover all of these requirements and metrics to define one job and build the metrics using the metrics keyword. The second thing, the benefit is that it run on parallel. So all of those metrics big jobs we want simultaneously, you will need enough runners available to run or you can run in a specific runner but configure it that it will allow to run multiple job concurrently. And user flexibility, users can define any custom metrics based on the project you need. So with that, let's see a quick demo. So I have here a GitHub project with Python application and let's assume that I want to test my Python syntax on different Python versions. So what I will do, I will use metrics build and it's really simple example. So use your job with the parallel metrics keyword and I define all different Python versions that I want to test. And as I mentioned, this will become a CI CD environment variables in the CI pipeline. And I use it here in the image, use Python and the version is the parameter that I define here. Once the job will run, it will run four instances of this job with different Python image. Let's see it live. So this is my job. We see if I click on it, I can see the different jobs that it automatically created. And now I can open the console and see the Python version. So the first line, it go and download the Python image. So this actually my environment. I want to test my code now in image Python 3.8 and if I will go the second one, I would expect that now it downloads image Python 3.9 and for here, I test and I see that it works on Python 3.10. So this makes my coverage that if they link all of those jobs we pass, I know that I'm confident that my programming language, the syntax works when on the required Python versions. And as you see, one job completed, the other still running. And this leads me to talk about the needs. Needs is part of the feature, not the feature called the directed acyclic graph introduced in GitLab many years ago, 12.2. So I know the name is Robust. And the feature is actually simple. And so normally without the directed acyclic graph, jobs running in stages. In this example, I have three stages, linked, test and container. Normally jobs running in orders. In order, so first the linked job will complete. Only all of the linked job will complete. Test jobs will run and only all of, once all of the test jobs complete, then the container needs jobs run. But as you see, not the situation here because I have here some jobs and they haven't completed, but still I have test job completed and also Docker build job completed. So in this situation, as you see, I have a pipeline still running. It may take time, the pipeline to complete, but I'm lucky I have a Docker build ready. I can use it and maybe other team that is waiting now, so this Docker build, they can get it without waiting to the pipeline that can take maybe one hour or I don't know the dependence on the complexity of the pipeline. But with the done, we can define dependencies. In this example, what I define is, I say that this job can solve running as long as this job completed. I don't care for those other jobs. But again, similarly, I define this job and start run once this job completes. I don't care for the other jobs. This is how I made some of the delivery already early. And let's see how we define this. It's also very simple in the GitLab syntax. So this is the, for example, the test 3.8 job. I just needed to add the needs keyword and define the job, the dependent job, and also which job inside the parametrics, in this case, I want to be dependent only on 3.8. So this is very simple. We now learned what is metrics built and what is the record of the secret graph. And you can read all of them in our online documentation here and about parallel metrics and how to use the needs with parallel metrics. Thank you for watching. I'm looking forward to see you in my next video.