 So, hello everybody. Nice being on this group. I am a life and data scientist working for a pharmaceutical company. And for a minute, I want you to sort of forget everything you know about Jenkins and actually remember everything about Jenkins. But what we're talking about is actually outside the standard DevOps operations. And all like, is it possible for me to share slides or can you? Yeah, you can just share your screen. Okay. You should be able to do that if not I will fix it, but you should have permission. So there's a share screen green button on your control panel. Is it? Okay. Can you see the slide? Yes. Thank you. Good. So I put the slides together just so that you have a frame of reference later on, if you want to go back and, you know, refresh your mind or some of these things that may be a little bit out of the standard realm of what we're doing with Jenkins. But back in 2013, I discovered Jenkins myself. I'm a trained PhD molecular biologist. But I went back to school and got a master's in software engineering, and I was for a long time interested in software development. And I'm in an interesting intersection of medicine and data science now, which makes a lot of these things really, really interesting. So back in 2013, I discovered Jenkins and has been using it since then, but we've been using it for a total different application. And a few years ago, we published this paper in scientific literature where we introduced Jenkins as a platform for scientific data and image processing applications. And it has nothing to do with actual compilation of code, testing code, and so on. But nonetheless, it uses all of the capabilities of Jenkins. So I really want to start by thanking a lot of people that have been sort of fundamental in this process. And interestingly enough, my boss at the time was called Jeremy Jenkins. And, you know, over the years, I've met many of the Jenkins contributors and very nice people in the group like Oleg and Marky and even Khashouki who visited Novartis a few years ago, Jesse. Importantly, my colleague who is now in New Zealand, Bruno Kinoshita, who developed some of the key plugins for this. And participants in the GSOC 2020 last year where we developed a machine learning plugin for Jenkins. So why use Jenkins for life science applications? Really, there are a lot of standardized things that Jenkins offers that are key enablers such as the accessibility of the jobs via web portal, the freestyle parameterized jobs, easy deployment. You know, the super rich plugin ecosystem. I'm not going to read this whole list, but these are what I call sort of the standard enablers of Jenkins that have made these possible. And the benefits that this offers is that life and data science pipelining really requires integration of a lot of utilities, applications, custom script tools, and Jenkins is able to do all of that. Finally, we have developed this concept of one page web apps on a shoestring. People can go to a Jenkins job interface and be able to execute an entire data analysis or data ingestion and processing and parsing in a very reproducible way that leaves a really good what we call data provenance path where we can always determine where the data came from. And finally, through this similar web portal, we're able to to share this data with others and collaborate. Nonetheless, you know, there is a kind of any impedance mismatch between develop and operations and science and just always as a kind of funny point. Bring this this word artifact that we're using in Jenkins. And of course, artifact is used with the idea of something that Jenkins creates. But for science, this is really a spurious observation and a bad thing, something that you do not want. So, you know, just that really kind of simple example of nomenclature where things are different. But let's look at specifically a pipeline jobs and builds. For developers, we check out of code from the SM. The pipelines are more consistent and continues. The jobs require very few parameters. The builds are almost always deleted and the artifacts are automatically tested on the scientific side, though, they. There's nothing such as the concept of an SEM for for data and instruments. The files are all over the place, whether it's on on a particular instrument on a local network drive, the pipelines are really discontinuous. It consists of an ad hoc mix of the Jenkins jobs different tasks are encapsulated in separate jobs that need to provide input and output to each other. The builds are almost never deleted because this is really primary data that you're generating. It's not a kind of a, you're not superseding all data or old jobs or old builds. And the artifacts are really inspected annotated and curated by the scientists rather than than in an automatic way. Another sort of impedance mismatch here is around job configuration, you know, for, for developers. Now, you know, we're moving more and more the pipeline as code, you know, Andrew mentioned the Blue Ocean project and I had some questions around its status because it really looked interesting at the beginning because it starts approaching the some of the requirements that are needed for the development of the pipeline. Scientists have around visual editors for configuring the jobs, but I have tried to use it and I realized that actually it's more for, you know, kind of the build stage and larger sort of not so granular that it is useful for configuring parameters and we use a lot of the freestyle parameterized jobs, which is not very common for the developers. So what we're missing and still is sort of this configuration exploration dependency management understanding where these things is what you see on the right hand side is a kind of my attempt to roll my own. This is actually the parameters in a particular job and they depend on each other. And so they depend on groovy scripts and script likes that are executed as part of the job. So this is sort of, you know, our own version of trying to understand the configuration better, but you'd be great if we had a kind of a better supported tool. Certain metadata are still issues, I think in the standard version of Jenkins, searching for artifacts across different builds is still very difficult. Build level metadata is not searchable and it's not generated very easily and the same thing across builds. I think actually Andrew may have touched on this as well around the artifact relationships. I call it relational builds where, you know, a downstream build may depend from two or three upstream builds and it's very difficult to sort of document that. And it's even more difficult to do a cascade, which we would like to do if you delete a primary artifact on which a bunch of analysis are dependent on downstream, you would like to have the opportunity to at least identify those. Here is a concept that is critical for what we're doing and it's totally missing from Jenkins. What we call this is the interactive pre builds, a lot of activity going on before you even start to build. And this has to do with the fact that starting a complicated analysis in our Python image processing, whatever requires the selection of a bunch of parameters that they may be appropriate or not for the analysis and going through a full build cycle. It's very expensive. And so what we have actually would like to do is have a bunch of pre build artifacts generated from by selecting different parameters and having the ability to generate a set of artifacts out of these those parameters. And then all the build does. This is some examples of the kind of artifacts we're talking about we're talking about images we're talking about scientific, you know, analysis that you visualize through graphs and even, you know, data tables and so on. And all the build does at the end is archives and reports these pre build artifacts. So for example, here you can see there was a report with six different pre build artifacts that are using different algorithms and different parameters to generate. And, you know, we have managed and this is the amazing thing about Jenkins that still sort of it's one of the greatest joys to work with it because, you know, you can, you can get it to do a lot of different things right even even this pre builds that I think the concept is missing from it. Now, something that may not go well with a lot of people is, please don't let security eat the function. You know, groovy script execution inlining JavaScript HTML are keys for the kind of things that we're doing. And we have been struggling and struggling to maintain their functionality in the present scheme of security improvements. You know, I know that Bruno has been very good at fixing security warnings and so on, but it's just the nature of what we're doing. And finally, I would like to say that, you know, we're talking about a lot of big companies are using Jenkins and about a lot of, you know, big installations Jenkins but for the life sciences and data sciences, we cannot forget how Jenkins would fit into sort of the environment of an academic lab where, you know, there is academic lab doing some research they need to deal with the data and their laboratory instruments, and they do have one developer there. It would be great if that developer can apply some of these, these kind of jobs that we have are developing for life science integration and data science. In a rather easy way. And that's it. I will leave you with a set of references. And if anyone is interested in hearing a little bit more about this, I think we have an Ignite session on applications of Jenkins and data sciences a little bit later. And we'll go in a little bit more detail on this. And again, thank you for the opportunity to speak on this on behalf of perhaps voices that you've never heard of. So thank you all like for inviting me. Yeah, thanks a lot for feedback. If you want to do extended session Jenkins online with up always welcomes you. And yeah, there's a lot of good points definitely it was discussing like I especially appreciate the point about security. And there are things like moral ocean, we discussed them a lot of the previous summits. I think that it's a really valid points from an user standpoint, or actually want to keep Jenkins as a framework for use cases like your informatics or whatever way you're still going to get like this out of the box but you want to use the power of Jenkins as an automation engine.