 Welcome everyone on our presentation, how to set up test infrastructure. So first of all, I would like to introduce myself. So my name is Szemon Rychelt and I am an engineering manager of the validation team in Poland. I work for Intel for eight years. And I have overall 15 years of experience in validation. With me is Mateusz Junker. He previously worked as a C++ developer. Now he is an OS development engineer in Zephyr. And he works for Intel for one and a half year. To give you some insight, I'll tell a few words how we get involved into Zephyr. So in November 2022, we were given an opportunity to start this new adventure in open source project. We joined a very experienced Zephyr team located in US and Canada. For most of us in Poland experienced mostly in Windows storage driver development and validation. It was really challenging, but on the other hand, very, very exciting. Working in open source project is so different. Well, collaboration with external vendors and people all over the world on delivering this great product. And at the same time, working with our internal Intel clients to fulfill their requirements. It's complicated, but fun. So let's move to the agenda. So first of all, I will tell a few words why we decided to build our new test infrastructure. Then I'll tell a few words about the test scope. And then I will pass to Mateusz to describe our new GitHub test infrastructure. And the last point, of course, will be questions and answers. To start, let's say a few words about the old environment. So our old testing environment was built using Jenkins. And I'm not going to say that Jenkins is bad or that our old approach was completely wrong. We still maintain it while in parallel we work on the new infrastructure. Well, working with the old environment, we identified few problems we wanted to sort out when going towards. So one of the problems to solve that we previously had was that there is a dedicated validation hardware environment. But most of the time the platforms are in idle. So it's really inefficient. And it consumes lab space, which is very, very costly. So let's look at the transition goals we have here on the slide. So first of all, we wanted unified and cross geo. This is really important cross geo hardware pool to provide access to do through GitHub actions. This hardware pool must be used both for pull requests and also to run our scheduled validation like for daily, weekly and other scheduled type validations. The third thing is that we really wanted to have a direct access for our developers and validation engineers. To do, for example, development work or maybe try some bugs. So as we can see on the graph, the target, the goal is to have one one hardware pool cross geo hardware pool. Working for CIPRs for schedule validations and for developers. The last bullet is that we also wanted to have an automated and unified way of reporting them. So let's move to the next slide. I will say also a few words about the test scope because this is also the area we wanted to improve a little bit. So we started to think how to test more efficiently and how to use our hardware in a more smart way and not to cause wear if it's not necessary. So let's take a look at the problems we identified here. So first thing is that all the tests currently are treated the same and selected mainly by built in filtering. The second problem is that the test coverage is controlled by metadata in Zephyr project primarily designed for optimized CI execution times. And third thing is that all classes of tests are executed on hardware. So this includes also tests that should be that are hardware agnostic actually. And the example is like a high level test or library code. And solution for this is well, we wanted to have an optimized test scope. What it means actually. Well, execute tests on hardware for those scenarios that cannot be covered through simulators and emulators. Now I'll tell a few words about the technologies we use to set up this new environment. So first one is GitHub actions and I'll skip it for now because Mateusz will tell more in the upcoming slides about it. We use virtual machines so we center and ESX hypervisors and why we use ESX? Well, it keeps the environment consistent. The machines are easy to recover and the environment is easy to scale. We use also Docker for standardization unification. We use Ansible for automatic deployment of dots and every machine which is necessary in the environment. We use Labgrid as a coordinator. But again, Mateusz will probably elaborate a little bit more about it in the upcoming slides. And last but not least, elastic search for storing and reporting. Now I will pass to Mateusz. Hello everyone. As Simon said, I will start from saying a few words about GitHub actions. And error hours, speed, efficiency and automation are paramount. GitHub actions has emerged as a game changing platform that revolutionizes the way that we build, test and deploy our software. The beauty of GitHub actions lies in the versability and extensibility. It allows developers to leverage pre-built actions or create custom actions to automate virtually any task in their software development lifecycle. Furthermore, GitHub actions foster collaboration and enhance team productivity. It's seamless integration with GitHub's repositories enable developers to trigger action based on pull requests, issues or other repository events, smooth code review, continuous integration and effective project management. With the power of automation at their fingertips, developer can focus more on building innovative solution and less on mundane repetitive tasks. I would like to share with you our common goal and strategy. We're aiming to achieve a blueprint that we enable us to realize our objectives through the implementation of specific phases. In the following steps, I will present the current progress and the next action we plan to undertake to move forward. So let's move to phase one that we already finished. We start with something simple to get familiar with environment to address some important points regarding the queuing system and the roles of runner and actors in our platforms. These points shed light on how our platform operates and ensure fairness and efficiency in executing tasks. The queuing system plays a crucial role in managing the execution of tasks within our platform. It ensures that each task is proceed in order and semantic manner. The queuing system is defined by runner. This is important here because it's a main role of runner. It is important also to note that all platforms within our system are reserved exclusively by only one runner. They have the necessary sources and capabilities to perform the designed actions efficiently and reality. At this phase, actor or other entities within our system do not have direct access to the platform. They do not perform tasks themselves but rather rely on the runner to carry out the necessary actions. This clear distinction ensures that the execution environment remains controlled. There is also no purity between scheduling tasks and the execution of pull request. Both scheduled tasks and pull request are treated equally and are placed on the same level within the queuing system. This ensures fairness and avoid any bias in our execution order. Let's go to the phase two. The next phase of improvement that we have undertaken to enhance the queuing system and optimize the overall workflow. Those advancements not only allow GitHub to effectively manage incoming requests but also provide a more streamlined experience for our user. In this phase we have made a significant improvement to our queue manager. Right now GitHub possesses the capability to actively manage incoming requests, ensuring that tasks are assigned and executed in time manner. This queue manager acts as a central hub, coordinating the allocation of resources and optimizing the overall workflow. As a part of our efforts to improve performance, we have expanded the numbers of runners available in our system. Those runners are now specifically assigned to different platform time, allowing for a more targeted and efficient execution of tasks. Where pull request is submitted, GitHub actively looks for an available and free runner to handle the request. This dynamic assignment process ensures that pull requests are processed promptly and efficiently. By actively seeking free runners, we minimize any potential delays and maximize the speed of execution for pull requests. And just as before, both scheduled tasks and pull requests remain on the same level within our queuing system. To maintain control and avoid problems, there is also no access from actors to our dots, like it was in phase one. Those advancements mark a significant step forward in improving the efficiency, reliability and user experience within our platform. The improved queue manager, increased number of runners, fair treatment of scheduled-based tasks and pull requests, dynamic runner assignment for pull requests, and restricted access for actors collectively contribute to a more optimized and effective workflow. I can say right now our progress is on the phase two, we already finished phase two and we are working to go and finish phase three. So let's move to phase three. I will say that it will be future goals because we are working on that, so the future goals in our queuing system are aimed at improving overall management and efficiency of the platform, providing a more tailored experience for both pull request and actors. So in this phase, we would like to introduce a coordinator to manage the queuing system. As Shemot said, right now we select lab grid, so the coordinator acts as a central authority overseeing the assignment and execution of tasks within the platform. This ensures a well-coordinated and optimized workflow as coordinator dynamically allocates resources based on demand and availability. So next improvement will be generic runners for platforms. To cater the diverse needs of different platforms, our runners have been designed to be generic. These runners possess the flexibility and the ability to handle various platform-specific tasks. By utilizing generic runners, we ensure compatibility and consistency across different platforms, streamlined the execution process. Runner resources will be chosen based on factors such as compatibility, workload and availability, ensuring that pull request or other events receive the necessary attention and resources that they are required. In addition to managing the queue system, the coordinator also grants access to actor within the platform. This means that actor are provided with the necessary permission and resources to carry out their assignment task. These controlled access ensure that actors can perform their duties efficiently while maintaining the integrity and security of the platform. So that's all on phase three and let's move the last phase, which is phase four. We can say it's phase four, it's a general schema. So the one significant improvement in the last phase is the separation of the reported runner. This dedicated runner is specifically designed to handle reporting tasks efficiently. By isolating reporting functionalities, we ensure to ensure accurate and reliable feedback on status of workflow and task. To enhance data management and accessibility, we have implemented two distinct databases. The internal database for storing and organizing critical information within our platform. Addictionally, we are introducing a self-hosted dashboard that empowers user to take control of data and workflow management. With this self-hosted dashboard, user can customize and tailor their workspace to meet their specific needs, creating a personalized data management environment. And the second one and the public board. So in our commitment to fostering collaboration and knowledge sharing, we are introducing the concept of public board. User will have the ability to share the board's test result to the community, enabling others to gain insight into their project, workflows and progress. This feature encourages collaboration, innovation and exchange of ideas among developers, allowing the growth of a vibrant and supportive community. In other words, community members can now access and utilize shared resources, enabling them to perform tests on real hardware. This opened an opportunity for more comprehensive and accurate testing, leading to higher quality software development outcomes. In conclusion, the separation of report runner, the implementation of two databases, the provisioning of shared infrastructure for real hardware testing, contribute to more collaborative, efficient and innovative testing infrastructure. We are excited to witness positive impact. Those advantages will have the development community fostering collaboration, enabling data drive and decisions in the service and accelerating software development. I believe that our determination, collaboration and dedication will enable us to successfully accomplish our objectives. Achieving success requires systematic and organized effort, but I'm confident that we are on the right track. Thank you for your attention and let's go maybe to some questions. Thank you everyone and yeah, we're waiting for your questions. Thanks.