 Welcome everybody. Why you attend? I am glad you attend, really, but I think that you have an important work then to be on this presentation. Before when then we start, feel free to ask about the presentation, not a beer or something like that. And let's start. Today is a good day for your GitHub projects. Why? Because your projects will be moved on the higher level. I do not want to go to the agenda, but why you go there to listen this talk? Because in your GitHub projects, you are testing on the one Linux distribution. If you test your project in the one distribution. And our motivation is, or maybe I will start differently. Do you know what you are shipping to your Linux distribution? Maybe? Who knows? Only to one. But we would like to bring you a new possibility. To test your projects, not in the one, but in the different Linux distributions. Like Fedora, CentOS, and... No, REL. But if this is a good RFE for testing farm, what is the outcome? Outcome is our tool, our tool is called testing farm as a GitHub action, which will help your project to test it and to understand what you are shipping. I like this slide. Because, especially being governed, shift left. Because we are trying to move every hour code close to the development. And again, I'm asking you, do you know what are you shipping? And are you sure that your code is working properly, not only on one distribution, but on the several? I don't think so. But this is a good talk for you. You can do everything. And when or especially, we will show you that it is possible. Your turn. Okay, so let's dig slightly into the technical stuff. So let's start with what is the testing farm? The testing farm is a testing service or testing system offered as a service. You may know compile farms. This is something similar, but you don't compile here. Nothing but you test your test here or your upstream project here. You can also view the testing farm as a black box, which has some of the inputs you have to provide to it and which provides you on the other hand some outputs. So if you want to test on the testing farm, you need the API key. The testing farm is communicating via HTTP API. The API key can be obtained from the testing farm team. Then you need to have a test management tool plan. That is the plan that describes your test that initiates your environment. And then you, of course, need the upstream test. As an output from the testing farm, you get test logs and test results. Well, and what is the best feature of the testing farm? I would say that it's an abstraction of the testing environment. You got a distribution as all you want. For example, Federa CentOSM. Well, and you also can choose from various processor architectures. At the beginning, I said we will talk about the GitHub actions. What are the GitHub actions? They are, or with the GitHub actions, you are able to build, test, and deploy everything what you are able to do. The GitHub actions automate all workflows, especially CICD, which is important. The question would be, what runners can we use? Ubuntu, Windows, and even Mac, of course. I did not hear it. Okay. With the runners, we are able to run or to go through the workflows, and we have several possibilities what to do with code. First of all, we do merging pull request. You are able to test the pull request and push to the, for example, in case of containers. In case of release, you are able to push your code like Python. Another pedal to Cipa, maybe go, I don't know where, sorry. You are able to deploy it and push to the repositories. And what is the biggest event of this talk is issue comment. When somebody of your project create a pull request, then you are able to test it. Not only with the Travis CI, but with the testing part to the several distributions. And of course, the last is scheduled builds. What are the scheduled builds? Let's say that you have a project and you need to know whether each day, each minute is working. And that is the aim of the GitHub actions. This is a brief overview. So we talked briefly about testing firm and about GitHub actions. So let's think now about how we can connect them together, how we can design them. So we have advantages of both of the services. Well, as we said, the GitHub actions can be used for describing the workflow in the YAML file and can be used for triggering the workflow. They offer runner and the runner can communicate with the testing firm via its HTTP API. So we can describe our workflow, the API and the TMT plan and the upstream test we can put into the workflow of the GitHub action. And we can trigger the testing firm as a GitHub action directly from the GitHub. Well, then we can use the testing firm for executing the test, which provides the benefits of various distributions and various process architecture, as I already said. And then we can display these results of the test and logs directly in the GitHub repository when the testing firm returns its outputs. Well, this is the workflow designed by our team, a CLR team, and how it works. And this is not only for our project. It can be implemented and it works in the different projects. We have already one, Leap, and another one which is ongoing. Well, let's say that you create pull request. First of all, you have to trigger the testing, not automatically. Why? Because if in the pull request is, for example, destroyed architecture by RM minus RF, this does not work. This is wrong. And therefore, you have to trigger by some command. This is specified by your YAML file GitHub action. The next, who can trigger tests? You? Are you owner? No. Only owners and maintainers of this repository can run the test. This is the second one. Sheddle the test. Okay. Second one is that the testing firm or GitHub action developed by us, sheddling the machine for you. CentOS stream rel. You have to write only the testing management plan for it. And this action periodically checks the output. As soon as the testing is done, then we are getting the final report for you. And the last, you will see in GitHub status what was the reason. Infrastructure problem can be. Failed? Your test has failed? Why not? Or even success on different architectures? Well, we are lucky because all this is already written. And we don't need to write it by ourselves from the scratch. And this testing firm as a GitHub action, as we already presented it, is available on the GitHub marketplace. So every open source project located on GitHub can already use it. And the usage is really minimalistic. The only thing, besides sheddling or considering your trigger of the action, is that you need to prepare your GitHub repository. You can use for the checkout action, for example, or you can do it manually. It doesn't matter. And then you call our testing firm as GitHub action and specify the two compulsory inputs, which are the API key, in order to communicate with the testing for API, and a TMT plan. The testing firm as a GitHub action is besides this highly configurable. There are so many other options which can be configured. But you can check it out later in the GitHub marketplace. Well, and do you know what can be incoherent in this slide or what can seem wrong? No. Besides that. Well, I would say that's the line with the matrix. And I would like to know that the GitHub action, if you want to run some action, some composite action as is this hour, you can do it on more targets. For example, if we want more TMT plan to be run, then we specify the matrix. In the matrix, we specify all the TMT plans we want to run this action at. And then just put the matrix variable here in the composite action, and it will be run for all of them. So it's just a note. Yeah. Because for the CentOS stream or REL, you can have totally different testing plans. And therefore matrix is used for it. Great. Oh, I forgot to mention something. Just when you will receive the presentation, there are some links. You can take an inspiration from our GitHub actions to your projects. If you do not want to use our GitHub actions, let's take an inspiration. This is a free. Well, this is a real life. You can see here that only owner, I don't know why I'm there, can trigger the test. You can see that OpenSheft 3 is not working. I don't know, maybe a rich land of life. Who knows? And you can see everything. What distribution was run for testing? What were the details? And that's all. And of course, is the code in your repository sane? I don't think so, because there is a red cross. You have to fix it. After this, when it's green, then you are able to tell to customers, our upstream GitHub repository is prepared for shipping. This is the last but not least presentation. There are several links which can help you to integrate. First one is our marketplace. The second one is important. Why? Because when you would like to use these GitHub actions, you need to be onboarded to the testing farm. There are two different approaches. Public or private. What is different? Simply, public is federal central, private is real great. Sorry? I like that comment. But you have to ask to the testing farm to onboard to allow the Ubuntu. Ask them. Why not? Because we have to test on everywhere. The first is our examples with the testing farm. How we are using. And what I can tell you is that all our containers used this one. Everything works properly around the hardware. And we already did some nice articles on the developers redhead.com. Feel free to read it. And you will see. And the questions. Have you already started with the implementation? Raise the hand. I like that one. Do we have a present? Where? Present? Nothing present? My mobile phone. Feel free to get the information from our presentation to include in your project. Because the customer needs to be satisfied with our code. That's all. Thank you. And questions to. Not beer. But to presentation. To start testing by comment also. But you are maintenance or trusted maintenance team. Yeah. Are some people waitlisted to always receive? I hope I will repeat it properly. Yeah. Who is able to run this testing farm? This is the great point. Thank you. Only federal contributors, redhead employees, is able to onboard testing farm for now. Nobody else. Sorry. Because we are touching closely to our infrastructure, especially REL. And you can imagine what will happen if your code is I'm saying destroyed our infrastructure for some reason. I don't know what. Especially if only those people are allowed, is it required to trigger test manually or are there, they started right after I made public that? The question is if the, even if the federal or REL authors are, needs to be triggered manually or automatically? No. Definitely. Each way manually. No automatic way. It is really. Well, if you use our composite action, you can define by yourself how you want to trigger the action. So you can choose from every trigger with which GitHub action provides. We use the issue comment because we consider it safe because we can check the only member or owner of the organization can run the account because if you obtain the API key, if your organization obtain it, you are responsible for the code that is running on the testing farm. So we decided in the STL org that we want to trigger the test only by the comment of the owner or member because we consider it the best alternative. But if you use this action, you can do it whatever you want, but yeah, you are responsible for it. But in the testing farm onboarding page, it's mentioned that the automatic triggering of the test is not allowed. And you have to somehow clarify that this will not be done automatically. I don't know why this was an NDA, let's say, but thanks for the question. Sorry, I didn't get it. Yeah. The question is, this testing farm action is run on the containers if it's able to run it on RPMs and stuff like that, definitely. This is not only for the container work, this is for every project. Did I answer correctly? No, no. By design, the question was whether testing farm is able to run on the multi-architectures. Testing farm, as a service, is able to be run on multi-architectures systems, but our GitHub action is not able to do it now. And personally, I don't know if we would like to do it. Of course, the testing farm as a GitHub action is an upstream project. Still free to file issue and we will discuss it with the testing farm team. We will see. Why not? Thanks for the question. Really thanks for the question. And good. Really sparking.