 היי everyone and welcome to our monthly CI updates. My name is Itzy Ganbaru, I'm a Senior Technical Marketing Manager here with GITLAB and our guest for today is Dov Erskovitz, a Senior Product Manager in the Verify Stage. We are thrilled to introduce the new approach of creating CI-CD configurations using the CI-CD Components Catalog. Hey Dov, before we jump to the demo, could you briefly explain what is the Components Catalog and how it can benefit teams? Thank you Itzy. So we can think about components as the smallest building block that with them you can build your CI pipeline. They are very similar to template. In fact, their content is almost exact. And the component catalog will be the centralized hub that help team to share and reuse component because what we've learned over the past couple of years that central teams normally face the following challenges when coming to build their CI pipeline. Number one, the first and the most acute problem is discoverability. Users won't know what is out there for them to use because whenever they come to build a pipeline they never start from clean sheet. They always try to find something very similar and then change it and update it because they say somewhere someone probably tried to build something very similar. So maybe I can reuse it. So discoverability is number one. And then after they find, let's assume that they find something that they can use and say, okay, now how can I use it? Maybe there is like a readme file. Maybe there are some documentation. Maybe there is a wiki but there isn't a streamline experience on how can you use the pipeline. And the last thing is once I can use the pipeline is it safe for me to share this with other people in my team because I'm not building the pipeline for myself. I want to build the pipeline so everyone could benefit and everyone could automate their workflow. So this is in a nutshell what are the key challenges that the component and the catalog will need to solve. Thank you, Dov. Now that we understand the value of the components and components catalog, let me walk you through a quick demo of it. All right, so this is the CI CD catalog page and here we can see a list of catalog resources where the user can see what is available and consume it. In each resource, you can see the version. On the right side, you can see when the component was released and who released it. Dov, anything to add here? Yes, so as you can see, this page is actually answering the first problem that I mentioned, the discoverability problem. And of course, later on, we'll enhance this page and help filtering and searching capabilities. Basically, the idea is to allow user to easily find and locate the component that they want to use. And if you click on the next page, if you click on one of those items, you'll be able to see the detailed page which help you answer the question of how can I use it and can I share it with other teams in my company? Very thank you, Dov. And this is an example of a readme of one of the components. So I'm as a user that want to reuse this component. Now I can use the readme and get a lot of details. And one of the interesting parts is the usage. I can see the component name and the description, how to use it, and the input parameter that it gets. And even I have an example on each that I can easily test and use or maybe just change the parameter. So now I want to gather in this demo, go and build a CI pipeline from components. So I will start by using the copy of the examples. And in my project, I have created a CI YAML file. It's clean. And we will just paste those components. I will go again to the readme and copy the second example and the third example. And I will just, will remove the include keyword because I have it once. And I have here included the CI CD pipeline that include only from components and their input variables. And now I can go in the web ID and commit it. If I will go back to the project, I will be able to go and see my pipeline running. It is important to highlight that this feature is currently in an experimental phase. Dov, could you share what your theme is planning to add before you can make it generally available? Yeah, so as you noted, the component and the catalog both are in experimental. And the reason for that is that when we introduce the component and the catalog, we kind of realized that we are asking our user to fundamentally change many parts in their pipeline, especially the move from template to components is a drastic move for our customers. So what we are aiming to do before moving component, we'll first move it to beta and then GA, but I think once we'll move it to beta, this is where users could really use it in their, I would say even their production system. The idea is that we will try to make template and component very similar because as I mentioned in reality, they are almost exact. Their content is similar. So once we'll do this change that we're planning to roll out in the next couple of milestones, it will be very easy for users to switch and convert their existing template that they use today to component. It will be like a straightforward migration. And then once they have a component, this is where they can actually leverage the power of the catalog. Now, the second improvement that we want to introduce is earlier in the detail page, you showed the README file. We are surfacing the README file of the project and the README file is something that the user needs to maintain. So what we would like to do is that based on those components that the user will create, we'll be able to extract the metadata information that is critical for running the pipeline automatically. So users won't need to maintain and keep the README up to date. The README will be up to date always and it will always be accurate. So this is the second change. And the third change is actually related to a design change that GitLab is doing, GitLab is moving to an organizational architecture. So every instance or every enterprise will have its own organization. So what we would like to do is we would like to align the catalog to organization because right now the catalog is bound to a namespace and the number of namespaces that you have in your organization potentially could be the number of catalogs that you have in the organization which is not a great user experience but once we will move to organization every organization will have one catalog will have like a single source of truth and will align the catalog that will be scoped to organization. Thank you, Dov. I can't wait to see it. Can you share what is the roadmap for CICD catalog for the next one, two or three years from your perspective? Yes, so as I mentioned this is an organizational catalog which means that only users in the organization are able to see and use the component in the catalog. What we would like to release next year is what we would like to call the community catalog or the shared catalog which means we will have like one unified catalog that goes and stretch beyond organization. Basically we will allow any person, any developer in the world to be able to create their component to publish it to the catalog and any user doesn't matter if they are GitLab users or not GitLab users will be able to access the catalog and see what are the available component that they can use. Basically will harness the power of community to help the individual developer to build their pipeline faster. Wow, this is really, really amazing. Thank you, Dov. So with that, we will conclude the demo. Thank you for watching. Stay tuned for exciting new features and updates coming soon. See you next time. Bye.