 So, hi, I'm Tristan Mutt and I work with GoThing. I'd like to talk about build stream and how it can help keep control of the integration processes. We won't have time to follow many questions today because this is a lighting talk, so please use my email to ask questions after the talk. Today I'll quickly introduce you and explain to you what build stream is. I'll show how this is currently actively in use in projects. I'll explain how I think the features shown are more broadly applicable. I'll actually show you the tool running and I'll summarize quickly at the end. Right, so let's go right into it. Buildsroom is an integration tool. In rough terms, it's a way to model the whole system required to build one or more software products. So, simply put, just build various packages together, integration system. It was originally a GNOME project, now Apache, mostly coming out of the requirement of having lots of open source developers work on an operating system that doesn't have specific source code anywhere. The goals for this were to build repeatedly. We don't want to be unsure if a build will work, if the code is okay. We want to be able to produce distinct targets because we want to deploy in lots of different formats, for example tar, cxs, doc images. We also want the state transparent doing so because it should always be obvious what the system actually contains. We can't not know what we're deploying or delivering. And at the same time, this should still be easy to use because we don't want developers to have to learn another tool. The outcome of this was YAML-based language that models these software stacks. CI tool to actually consume this language, as well as sandboxing a cloud build infrastructure to facilitate builds of this software stack. Right. This is all a bit abstract, so let me get to a slightly more concrete example. This is a little toy example of what I think a Firefox build would look like. The boxes that you see here are elements, which is the build-in-term analogy for something similar to district packages, although they are a little bit more powerful. And on the right here, you can see my rough estimate as to where these packages belong. So at the core of a build-in-term model, you have runtime, usually, which is just core utils with some compilers, usually an image of the actual target system. On top of that, you have libraries, which are the direct dependencies of an application. On top of that, the application sets, which needs these dependencies to build. And on top of that, we have the deployments, which need the application to build. Now you might be wondering what BuildStream does with these elements. So this is what an element looks like in BuildStream at the bottom bit there. This is the GTK element from the previous slide. As you can see, GTK is built with Meson. BuildStream will figure out which commands to use for that. The source code where to get it from is listed there as well, as well as the dependencies, which in this case is just a runtime. BuildStream, with one of these elements, it will download and verify the source code that we need for it. It will prepare the build dependencies, which just means recursively follow the steps that you do for this element, basically. It will prepare a sandbox, and this is the important bit, with kernel namespaces. So this will ensure that only the specified dependencies are actually in the sandbox, as well as the source code for the project. With the sandbox, we can then invoke the build commands for the build system. And when we get a result, we store that for later builds. This is still a bit abstract, I'd say. So let me just show you an actual project that uses BuildStream. That is FreeDestep SDK. FreeDestep SDK is a completely separate project that tries to be the canonical SDK for the Linux desktop. Naturally, this means there's lots of packages for various different deployments. And they use BuildStream to facilitate this. So this here is a diagram of one of the parts through this SDK system, specifically the one that will build docker images. And let's start at the bottom again. So in this case, the runtime is what they call the bootstrap. This is a stage three that is built entirely from scratch, just call utils and ggc. This is built using a stage one of an old version of this SDK. I really like this example because it really just shows how much detail BuildStream can actually define. Even the very cool runtime can be built inside BuildStream here. On top of that, FreeDestep SDK builds various libraries for the platform and the SDK, where the platform is just a normal deployment system and the SDK is the actual development system. The platform contains things like fmpeg or curl, whereas the SDK contains things like cmake and gdb. On top of that, we have the application layer, which in this case is just collections of these packages. On the left side, we have the platform, which contains the usual packages that will actually be used to run. And the SDK includes the platform to have all of those packages, as well as the developer tools, which are then deployed into the various OCI formats. These are just docker images. So I will show you this actual building in a minute, but first I'd actually like to talk about why we do all of this. The first advantage that I've already alluded to are the sandbox builds. It means that we know the exact build provenance of a system. This means we can't have something like an accidental old OpenSSL compiled into a binaries. We also get a full transparent view of the software, all its dependencies and deployments. This is very nice to have, because you can actually reason about the system you have and know what's inside of it. This is in the build stream world, a hierarchical set of package definitions. You can have similar things in docker files in search, but I find the CMO format significantly easier to understand than comments in a docker file. On top of that, the build system is fully defined inside the element. This means that there is no gold server that we need to maintain separately without any EU supervision. Rather, the build system is defined and built from scratch every time that we build the software. And the changes to it can simply be made with git commits with all usual tooling for that. On top of that, we have a programmatic system definition. This makes other features significantly more feasible, such as build shells that allow developers to look inside what's happening inside the build. Cloud-based builds, we can just push around images to actually make the individual steps of the build. As well as automated license verification. We have some example projects for this, they're mostly still work in progress though. Right, I will show you a build stream, actually in action here. This is the 3despus scale that we were talking about earlier. I'll show you here what we're building. This command will load up all four elements and show that current state. You might notice that most of this is already cached. Build stream will remember what it has built previously and just keep those elements around. One of these elements needs to be built still, for that we invoke the build command. Build stream will start going on its merry way and actually pull the sources and dependencies together. Until eventually it finds out how to build a sandbox and it's quick and already starts running the build commands here. This will take a bit, actually skip ahead in time a little bit there. It completes its build, at which point it has its build artifacts somewhere deep in the file system. We can check this out in the directory. I missed that there actually. Let me fix that. This will produce a directory that we will have to tar off so that Docker can actually load it. We'll take a second. Yeah, that's the contents of that file. Put up a tar file. Docker unfortunately needs to consume a tar file. It can't just eat the raw directory. We input that and in a second I will run it and prove to you that it actually works. Again, there's lots of features here. A lot of what's happening in here is not covered because it's difficult to cover everything in 10 minutes. Just showing off the actual file system. That's the host name inside the Docker container, which is different from my host host name, so you can see that it actually works. Nice. Alright, in summary, build stream is a tool that helps us provide insight into what is included in the deployments. Even hidden details like the compilers of our dependencies. It helps ensure a build environment closely matches our expectations. And it has tons of other features. Please see the documentation for this. Well, what I'd like from the audience here is please give build stream a try. Tippano is coming out soon. We won't use cases for this before the next API hits, stable API hits. So get them in quickly. Feel free to ask me any questions via email and thank you for your time.