 All right, perfect. Welcome, everyone. I see some new faces there. That's good. We have a working doc. I will add that here. It's already in the invitation, but I want to make sure that you have that in mind. So, quick intro since we have new faces, we want to talk about spitting the the some faces in the analyzers, especially with the build and the analyzer face. The problem that we have is mostly that with various environments, it's hard for us to support all edge cases and all the cases in the world, like all the different versions of Python or Java or whatever, and the only way to achieve that is to have two-phase process. So, that's why we started to discuss that kind of things. And so the first node that I added to the doc is we have a customer that have exactly that kind of need. They have some Python project and dependency scanning is not working because we are missing some operating system dependencies. So, it's the same story over and over again. We need to provide a way to the users to provide their own environment, meaning their own version of Python, for example, and their own system dependencies that they will install. So, one way to achieve that is apparently to use the workspaces, but I'm afraid workspaces won't be around for a while. I see a 12.4 milestone in the issue, but I'm not so sure that it's going to be available in 24. Yeah. I think that's one thing that we've talked about. I don't know if we've said this before, but we could always work cross-functionally, and if it's so important to us, we could contribute engineering resources to verify its effort. But I think one of the big issues is that requires so much domain knowledge that we can't really, I don't know how much we can do to work on that portion of the pipeline to try and get that feature done earlier. Maybe I'm wrong. If anyone here has more experience with working on that portion of the code base, then it could be worth exploring. Yeah, that's a good point. If we want to find a work command, we need to find a work command that we can do before the actual availability of workspaces, otherwise it's not work. If we start to develop something that would lead to have something like the workspaces in the end, it's not very useful. Based on the fact that we don't know when exactly the workspaces would be available, and even if they would be available right now, they would not solve all the problems, especially with regards to the dependency injection. Even if we add workspaces right now, to give you a quick idea of what workspaces are, it's a way of stacking over the same environment again and again. It's pretty much what we want to do. So you have, for example, a Python environment and you install all your dependencies there, and you can use that as a kind of base image. And every time you run the job, it will use this very same environment, maybe add some more layers to it like you would do with the Docker bird, for example. But it's going to be shared between the jobs. So it's right in the middle of the artifacts, the cache, and the Docker images. The remaining problem that we have is, even if we add that, we need a way to inject, for example, the dependency scanning analyzer into this workspace. So my idea there, and that's what I want to explore today with you is maybe we could have something because we could have something in the middle. The problem that we have is we're trying to either start from a base image that is not ours or use some base image that is ours, but reuse that into the user's environment. So why don't we have something like in dependency scanning, I would have the base image provided by the user, and in the script or the before script, we would do the installation of the analyzer that we want to use it. It should be generic, but it could be also specific, like I want the Python analyzer, or I want the dependency scanning analyzer on the other hand. But by doing that, we should not rely on any of the system dependency. I think that's the case today. So it should work. It should not rely on a specific version of Python or Java or whatever. In this case, the user would have the ability to install their required dependencies like PostgreSQL, contributions, different packages, etc., etc. And then we ask the user to call the analyzer that we want. Yeah, similar to what Fabian was suggesting in the approach where we were just executing the analyzer within the context of the build job, like defining some steps, some scripts, actions, like what's the process to set up the analyzer environment. So yeah, it can work. It can work. And it's probably easier than trying to to mix two different base images. No, this is essentially releasing binaries, right, from what we talked about before. No, you don't need to have the access to a binary. Sorry, you mean just a binary for the analyzer? Yeah, okay. So it's like, yeah, it's a kind of multiple steps. So in start, it's just very quiz it. Download the binary of the analyzer and execute it. Yes, that's it. And then we were thinking like something as simple as just a curl to a script and a bash and pipe it to a bash or some other shell to make it a one liner. And here, if I understand here, the goal is still to have that in our specific job. So we can have a detailed script that could be easier to maintain. Just a quick thing to recap for me. So when the user, for instance, I remember we had lots of problems with Python projects. If a user of Python project initiates its CI pipeline, so different builds are these build steps that are required to actually build the application and to prepare it for SAS scaling. Are they different? Or is it actually the same build step that the user usually executes before building and releasing its application? So why asking this is that for me, it looks natural that all of the dependencies should already have been installed before scanning by our analyzers. So maybe I'm missing something. We are talking about adding the dependency of the analyzer itself here. These build steps are for installing the environment to run the analyzer itself. All the dependencies from the project build has already been installed in the build job and is exported into this base image that we are talking about. So we get this other of the build step, put that in a base image, load that image to run our SAS job. And from there, instead of having our base image containing the SAS analyzer, we just use the base image from the user. And in there, we add the script, like, install the SAS analyzer, then run the SAS analyzer. What could go wrong is for specific tools that need a specific environment, we might need to just reinstall some stuff. But I mean, like, we have a Python 2 project, but we have a Python 3-only compatible analyzer. This means the project is built within Python 2 and everything is installed correctly there. And then we have a base image on this. And then what we do is just install Python 3 and execute our analyzer in the context of Python 3. Said like that, it could just work. But I'm expecting some edge cases where, I don't know, maybe some of the analyzer will require runtime live execution of some, I don't know, crazy stuff. I think mostly about gymnasium Maven plugin because for Maven analysis, we have a gymnasium Maven plugin. So I don't think it's the case, but it could require Maven, I don't know, one, two, three, which we try to rebuild the project or at least try some Maven cycle commands, which might not be compatible if the project is not using that version of Maven. But I think those are very, very edge cases. So we might just don't bother with that right now. So if we were going to release our scanners as corollable binaries, then we would need to have potentially two different Python 2 and a Python 3 dependency scanning binary. And just like anything else, you could fetch the relevant one to scan your code. If we can, yes, that could be another option. And we can do that today. Like with our Docker containers, though. But I feel like we don't do that for a reason, which maybe it's just inconvenient. Because we didn't thought about that, maybe. And yeah, it requires a different name scheme for the images, probably make it harder to set up. Can you repeat that? I was fighting with Google Docs and getting crazy. Okay. So ignoring the entire working group we're doing right now, the proposal I was saying was right now if we have Python 2 and Python 3 issues, why don't we release a Python 2, a gymnasium Python 2, and a gymnasium Python 3 scanner? That way we don't have to worry about one scanner doing both. And in a similar way, if we're doing this approach where we expose a binary, fetch it, and a user runs it in their container, we still need to release multiple release versions. In some cases, that might have to be a different architecture too, like Windows versus Linux or something. But either way, we're going to have to support many different releases. Yeah. And yeah, the problem with that is we're only solving a portion of the problem. We're solving the interpreter or the compiler version in compatibility, but all the system dependencies, that wouldn't solve, for example, the customer case that I mentioned earlier on this meeting. Did you take a look at that point? I just added that the bottom of the doc, which is pretty much the opposite of what we're doing today. Not sure if it's clear for everyone. Yeah, I think that the issue is that this currently requires a user to be producing a Docker container for their build. Otherwise, what happens is maybe you just left that there for like quick sake, but it requires the image to be a user-provided image. And we normally, when we're all with workspaces, use a previous job instead, definition. Yeah, the idea is we do all the artwork in the template. What you're typing, Olivier, would be in the template, actually. We don't need that right there. That's the point. Yeah, you're right. It was for comprehension, but you indeed write this should be in the template itself. Just to explain that. Yeah. Okay, I just... I'm not an expert in Docker, unfortunately, but is there an opportunity to share some volume between Curl, excuse me, Analyzer Image, and User-Based Image? So the User-Based Image would have to, like, will have shared volume directory with all of the... It would be actually a working directory, and it will let us to maintain our current release schema of Docker images for our analyzers. Wouldn't it make us... Would it make it simpler? We won't have to shift our release model. We can't use module because we have an isolation between the Docker executions. The only thing that we could leverage would be the artifacts of the cache, which is actually the same. It's not a volume, per se, Docker speaking, but it's a kind of file system that you can share between the jobs. But even if we do that, the artifacts are limited, for example, to the current build environment, the current build directory. So, if you install anything at the OS level, it's not going to be part of the artifacts. We could use the cache for that, but I'm afraid it's going to... I've seen some edge cases where it would not work, because you would basically override the world current file system, and I think it's not going to work. And it's the only way to achieve that. But the idea that I want to discuss here is a bit different. It's... If the user doesn't provide a base image, we could use the default one that we have, for example, today, which is backpack-compatible. But if you have something very specific, like, I have a Python project with SQL2 in start, and I need for that, the postgres step package installed on the system, then we can ask the user, okay, you have some specific needs, you need to provide one image. The way to provide your image is here, you provide that image. The script would remain the same. Actually, in the templates, we would curve the binary, or actually, I was thinking of also apt-get install something. It should not be hard to provide IBM or Alpine packages that would work on many, many, many different distributions. It's not really that hard. I've done that in the past. And so, in the script, by default, we install the analyzers, we install all the files that we need in the image, whatever the image is, and by doing that, we also open the door to, okay, maybe you just have a base image that is Python 3-specific. If you need something even more specific, you can use a default script here. And apt-get install what you need there. By doing so, we don't need the workspaces. We don't need to update the CI, the runner, anything in GitLab. It's pure template and job magic. Does that make sense, what I'm saying? Am I missing something of use? It seems to be too good to be true. That's the problem. Can you please repeat that part when we are getting rid of the base image, the case when the user does not provide the base image? Yeah. So, the idea is to work the other way around. So, what we are doing currently is not what I wrote there. What we do is we have our image that we built and we put everything that we need in there, and then we use that image with the project of the user. So, we kind of import the project within that image and we run the analyzer on that. So, that's the problem because we use our image. In this case, it would be the other way around. So, by default, we would use that same image so that it's quite compatible. But if you are a user, for example, with a Python project and you use Cyco2, which requires PostgreSQL Dev to be installed, in this case, we could tell the user you have a specific need. You need to provide us, you need to give us a base image and we would do the rest. So, we are in the full environment of the user. We have the dependencies, the OS, the interpreter, all the compiler, the project itself, and we are injecting the dependency You're going to install an analyzer into the user image. Exactly. The only problem that it would create is, does the analyzer work in any condition, like I have a Python 2 or Python 3 interpreter, is it going to work the same? We might need to adapt the bits, but if we do so, we have everything in the rinse today to achieve these kind of things. We can also detect if it's a dbian-based OS or an alpine-based OS and run a ptget install if we have multiple files. It's probably going to be easier than cure because we don't have the support of binaries or releases right now, apart from the artifacts, but it's not super clean. Oh, you just put that in the repo. We did that before. You wrote that word, sorry? You just put the binary in the repository. It's not the best. Otherwise, we can also wait six minutes and Python 2 will be dropped. Well, that doesn't solve the problem of this. The aptget install PostgreSQL is that. There's no way today to achieve that. But there's also the issue of air gap systems, right? And so I was wondering if with this current approach, we would require a customer to post one of our packages elsewhere. And I was wondering if it would be possible for, so assuming that we can do everything in NPM, could we ship our own binaries in customers NPM registries within GitLab? I don't think so. That would be the same as for shipping the Docker registry with pre-installed images, maybe. That's a good interesting idea, by the way. Right. Maybe it could be part of a setup script to pull some images or to install some images there, but that's a definitely interesting way. Because there will always be that issue. And if customers want to avoid, currently, we just say you need to host our Docker image. But for the binaries, we need another solution for that as well. And honestly, it's a bit easier for customers to retag and re-host a binary on an internal registry. But if I were to tell a customer, like, yeah, I just hosted your own binaries, I mean, everyone probably has a CD, it seems more awkward. I don't know. Speaking about binaries, I wonder, are all of our analyzers can be just expressed as a single binary? For instance, our Python analyzer, isn't it a collection of scripts or maybe like, I haven't honestly dive into the repo, but I feel that we need to be sure that all of our analyzers actually can be compiled in a single binary. And I'm not sure about that. No, because most of the analyzer is a binary, but it's just calling system commands. So we're basically rehashing an issue that we worked on a while about called leveraging existing builds where the solution that we came up with was basically what we're doing today. But I did look in that briefly and there's a tool called Packager, which is basically a way of just including static files in a Docker binary. It just pulls the files in. So we could do something like that, but it's pretty messy and it doesn't quite include everything. We basically have to include entire runtimes in a single binary. There is a way to go to include assets directly in the binary, but I'm not sure it would be super nice because if you do that, it's mostly for assets when you do that kind of things. When it comes to, if we have any system dependencies not going to work because some of the dependencies, they require some very specific rights on the file system or very specific path on the file system. So I would definitely push in the direction of having DBN or L-Pine packages instead of a single binary. If we have a single binary, that's fine. But anyway, it's something that we can iterate on because if we have the control of this script, which is the case, if we add that to the template, then we can start with the binary and use whatever we will suite on it in the future. That's why I like that it's retro-compatible. We use the same base images as today and project analyzers. That's something that we could try. I don't see any case where it would not work out of the box. I don't know why we haven't thought of that before. So the option we choose as our primary option to go next for is packaging our analyzers. I mean, Linux packages. So that's one thing. Another action item that we can take today is we need to go through each of our analyzers and explore splitting out the build and scan stages. If we essentially wrap all build stages in a command line flag or an end bar, then it will make it easier for us to transition away. So as part of the move towards splitting, one of the actions we can take today is to start refactoring our analyzers to make it optional and then eventually pull in that binary or pull in that other part of that. I would say in this case, we can detect if we need to run the build. In this case, we would run it like what we are doing today. If it's not working, that's a shame. That's exactly the problem that we have. Because we're not going to create new jobs. That's the problem. We need to have something that would be backward compatible. Otherwise, we will create something for 13.0, which is the next major in May next year. I think that if we can make that retro compatible, we can have something before the end of the year, which will solve the problem. So refactoring the analyzers and what was the other action? Oh, binary. O2 package. Stand alone in the analyzers. All right, we are out of time. I would like to carry over one more action from I think last week or the week before too, which is like we should look at the link that you shared at the beginning here for our customer. We should target a real-world use case for this. So instead of a figure out how to ship standalone analyzers, maybe figure out how to ship the gymnasium Python analyzer standalone. So we have a more actionable step. I also feel that there is plenty of information to collect across all of our analyzers and also example projects. So we need to choose a yes or the place where all of this information will be collected, like in the description of an epic or description of an issue, maybe in some tabular data, what analyzers already support, detecting the need for a build step, what analyzers do not. So all of this information will be in front of our eyes to easily navigate it and to easily understand what is the current status of this research. Do we have an epic or an issue for this initiative? I don't remember. We have the domain issue, so we can probably start from there. You'll never find it again. All right. I'm going to stop sharing now. Well, that was useful. I will update the issue with all of this, and I will keep you posted. Thank you very much for your collaboration and suggestions. See you next week. Bye.