 Hi, everyone. Welcome to the Jenkins online meetup. My name is Alyssa Tong. I am a long time Jenkins contributor in the areas of events and outreach. Today we have a presentation by Oli Huffner on how he eases the complexity and increase ramp up time for Jenkins environment development, Jenkins development environment setup. His co-presenters are Jean-Marc Mason, Darren Pope, and Marc Waite. I'll let our presenters say hello and introduce themselves. Hi, my name is Oli Huffner. I'm a long time contributor to Jenkins as well. I think it's almost 15 years now. I'm the author of the warnings plug-in, the differentics plug-in, and a couple of more plug-ins I'm handling. In my real life, I'm a professor for software engineering at the University of Science in Munich here. I'm teaching students software engineering, software development, and so on. I'm using Jenkins in my lectures to show them how to improve the quality of their code, and this is the presentation we are talking about today. Thank you. Hello, my name is Jean-Marc Mason. I'm located in Brussels, in Belgium, and I'm helping out on the Jenkins projects trying to help developers. I've been for years senior DevOps consultant and a long, long time Jenkins user, even in the time of Hudson, in the beginning of that. Hi, my name is Darren Pope. I am a developer advocate for CloudBees and also co-host a podcast with Victor Farsik called DevOps Paradox, and I think Marc and I might end up talking about some of the things we did back in October today too. We may. I'm Marc Waite. I'm a Jenkins documentation officer, and I've been using Jenkins for a long time. I happen to also be one of the maintainers of the Git plug-in, and I'm quite active in documentation and platform topics. Thanks, Alyssa. Thanks, Marc. So before we dive into the presentation, I would like to highlight a couple of things, some upcoming events for Jenkins. So in February, we will be hosting a Google Summer of Code 2022. If you'd like to be a part of this program, we are looking for organizers, mentors, project ideas, please reach out to us. I will leave a link in the comment window on the Meetup page after this event. And we're always looking for presenters for our next online Meetup. So we're planning to have more of these to bring helpful content to our community. So if you're interested in speaking, you've got a great story, please reach out to us. There's more on this at a later slide in this deck. In June, we are planning to be in Austin, Texas with CDCon, where we will host a Jenkins contributor summit. And again, if you have a great Jenkins story, the CFP is currently open. Please submit your stories. September DevOps World is the largest event for Jenkins, and this is taking place in Las Vegas this year. Again, we will have a contributor summit on site. And we want to give a shout out to our sponsors, CloudBees, and the CD Foundation for hosting these events and allowing us to be part of their events. So Jenkins needs you. We are always in need of technical and non-technical volunteers. This is how you can participate in some of the programs. There's organizations for Meetup. There's translations for documentations. There's testing, coding, you name it. We're always in need of volunteers. If you'd like to give back to the community, we'd be happy to have you. And it's also a great place to meet good people. Jenkins online Meetup, as I mentioned earlier, this is a place where we hope to bring more Jenkins helpful content to the community. So if you have a story, please reach out to us. You can go to this link to find more about it. So before I hand things over to Oli to start the session, just a couple of housekeeping items. This session is being recorded. We will post the link in the Meetup page after the event. Q&A, please put your questions in the chat window throughout the presentation. Our presenters will get to them throughout the presentation. And lastly, our code of conduct is fully enforced here. And if you don't know what that is, simply being kind will do the job. So at this time, I'll hand it over to Oli. Thank you. And I will pin my video so you see me in the full screen mode. So what is this talk about? I want to talk about the development environment I'm using for my students to just continue and start development in Jenkins. So as already mentioned in my introduction, I'm using Jenkins to show the students how to do continuous integration, continuous deployment. But I'm also using Jenkins in my courses to see how an actual software application works, how you develop the code, how you develop the tests and so on. Students can use this code to improve their skills. And we have also master thesis, bachelor thesis or some kind of exercises which work with Jenkins. So the students can work with real code, which with real code, they can review and whether they can produce their pull requests and we integrate these pull requests in Jenkins as well. In these courses, it was always a little bit difficult to start the course because typically the development environment of everybody is a little bit different. Some people use Windows, some use Linux, some use Mac OS. This is always kind of difficult to get everybody having the same machine where we can start developing. So one first step what we are doing at the University of Applied Sciences here in Munich is we hand out for each of our students a virtual machine with Linux. And this virtual machine is not part of this talk now. This is a kind of pre-condition. We give everybody a virtual machine which has a bunch of Linux installed and every tool you need like Maven, Git is already pre-installed. So if you have Windows without Docker, it does not really matter. You get this virtual machine and then you can start developing. So this is for all of our courses. So this is nothing that comes from me. This colleague of mine is this doing. And now I'm coming in and want to develop plugins for Jenkins or to show how Jenkins is working. That means I also need some kind of setup how to build Jenkins plugins, how to start Jenkins and see how these plugins actually behave. And this was a manual process in my first courses. And after doing this course again and again, I noticed this is better if you have a setup which is easy to install on each student's machine. This has also a good side effect. I'm using the same setup for the contributors, a document of my warnings plugin and of the code coverage plugin and of the Git forensics plugin. So new contributors to my plugin also have the opportunity to have a good setup of things we need when we want to develop Jenkins plugins. This is what I would like to show you a little bit in more detail today. So the topic is this GitHub project. It is currently still in my personal account. That's because I'm using it at the university and it's not really from the Jenkins project. But yeah, I'm not sure if I should give that in the chat. So if someone did not see it again, this is the URL of this development iron project. And this project basically contains all things we need for our development setup in Jenkins. So just a brief sketch in the beginning. Basically, this environment consists of three things and I switch now to my screen. Then you will see the project here in GitHub. So in GitHub we have this project and it contains a lot of files which are not so important. The important thing is so in the beginning what actually is part of this development setup. And basically I have three items which are required for students to begin. The first thing is they need to know which is the actual code, which plugins would we like to develop in Jenkins. So my students work not in Jenkins Core. We are always heading to development of Jenkins plugins. So the first part which might develop an environment contains is a setup of all these plugins that are required for the students. Currently these are the warnings plugin, code coverage plugin, the forensics plugin and so on. We'll see it a little more in a couple of minutes. And these plugins are automatically checked out so the students do not need to worry where is the source code of the file. I have one script provided that checks out all these modules. These modules are currently just my modules. So if you want to develop in the kit plugin for instance you need to change those scripts. But this should not be really hard to do. So this is the first setup. You get all the modules you need. Then I have a multi-maven project created which compiles all these projects. And using these compiled projects I've created an IntelliJ project which everybody can import in his workspace. So they just need to click import in IntelliJ and wait a little bit until IntelliJ opens and indexed all files but then you can immediately start developing. And the last part which is quite important for Jenkins is that when you're developing plugins you want to see the results of your changes. And these results are best seen not only in unit tests but they are best seen in an actual running Jenkins instance. And therefore I also package in this development environment a Jenkins installation which is ready installed with a lot of plugins I'm needing with a lot of jobs which already use these plugins that the students will change. And finally what is also part of this installation is we have a Jenkins controller which runs only the user interface and we have a Jenkins agent which runs the actual builds. This helps me to develop already for a complex installation where we need to have a distributed environment and there are a lot of bugs coming if you are not testing it in a distributed environment. So this Jenkins installation as you will see later on will use one agent and one controller. Both are Docker containers so they are installed on your local machine but there you can have a good opportunity to debug your code in a distributed Jenkins environment. So Uli, you just described what sounds like near Nirvana for me. So as a plugin developer you're providing a setup that I can run Jenkins. It's already got an agent configured. It's already got interesting jobs configured and I could potentially even offer additional jobs to that as a pull request to your repository. Yes, this is possible. So I will show it now in more detail what these elements are. So this is just an introduction to. So I think the best thing is I show you now how you interact with all these three components and then we see how you can use them if you want to contribute to Jenkins or how we can extend them if we need different modules than the warnings prepping. So the first thing you need is you need a terminal where you can clone the code. You can use a user interface as well but I'm typically cloning the repository on the command line so you can use the GitHub console. For instance here I'm checking out the repository and cloning it on my machine. So this works with GitHub console or you can use Git clone and clone it under a different name. Let's say and then I'm cloning these modules. That means after this clone command I have this project which I described here from GitHub on my local machine and then I can start to build the project. So the first thing we need is the plugins we want to develop. So let's go to the folder and let's see what we are. In this folder we have a lot of scripts but actually not many source code files yet because these source code files are not here. What I need is I need to transfer all files from GitHub to my local machine now and I'm using a simple shell script to get them from GitHub. So I started using with GitHub modules but that didn't really work out so I'm just using a script and get all the modules of my plugins on my local machine and therefore I have one command which is called clone repository. There is the possibility to use the Git. If you have a Git key in GitHub you can use get a clone repo shell script or if you only use HTPPS you use the different command. So both commands are supported and if you run this command then I'm getting all the content you need to start development. That means all modules or all plugins from GitHub and if I press enter then you need to see there are different clone steps right after each other where we get from GitHub the source code we need when we are going to develop the source code. These are now only my plugins so if you need different plugins you need to change these scripts. So conceptually could I offer a would you consider a long-term branch on your repository that might be dedicated to somebody else's plugin like the Git plugin? Yeah that might be a good idea yeah. I'm not sure if it's possible to make it a parametrized. This is a little bit more work but I think a different branch would be simple. Okay great thank you and you're open to that kind of thing. If I wanted to propose such a thing you and I could discuss it through pull requests and what. Yeah that would be fine. So this is the first step now all my code is on my machine and now the code is will be compiled using a maven that means yeah I press now enter and now I'm using maven a compile for this project. This takes a little bit it takes I think almost 10 minutes on my machine so I'll stop it here and I prepared it already for you in another window so I'm switching to this window where we are now finished so we saved a lot of time because you see it's almost 10 minutes the build typically requires and it's quite important to start a full build of all these modules you need because I want to import this project now in IntelliChain and here you see all the plugins I'm downloading this was my coding style it was the static analysis model code coverage API forensics API that's almost 10 modules which are part of the setup I'm giving the students and typically we can make a smaller setup for individual people for instance like the git plugin we just need the git plugin and maybe the git client plugin I started with different branches for different use cases but I then considered it's easier for me to have just the single branch with all my plugins and some students just use the analysis model placid package and some only the warnings plugin so yeah it's just easier for me to have 10 modules here in in one branch rather than having them individually and so Uli you always start from the sources these are the plugins of interest do you need other plugins a more statical one where you used the released one or you always go from the sources I'm always going from the sources because my courses are always about source code development so we're writing tests so we're developing new functionality so we need to have the source code each of these source code has a lot of dependencies of course and they are automatically grabbed by Maven and if I deploy these plugins in Jenkins the depending plugins are also automatically pulled so as we see later on the Jenkins instance already has a lot of plugins because of the transitive dependencies so after we compile the source code we can open the source code in IntelliJ this is the next step so we need to compile them in advance because in Jenkins we are generating a lot of source code during the Maven process and IntelliJ doesn't handle that quite well if you start IntelliJ without generating the messages for instance or the assertions etc so it's important to make a build first and then you can simply open the whole project in IntelliJ when you open the project in IntelliJ I don't know if you already used IntelliJ then IntelliJ is indexing all files it takes also a couple of minutes so what I have done is I started that step before the meeting so we now have already the IntelliJ project open so if you start this setup in IntelliJ you see this a few that means the read me on the right side and on the left side you see the tree of my projects and you see here the analysis model the code coverage plug-in my coding style um yeah this is something which is not related to Jenkins um I'm using a coding style for all my development courses in where I have defined which checks time warnings are relevant which spot bugs warnings are relevant how do I want to format the code and I'm using it in Jenkins as well so it makes sense that this project is also part of year of this development environment there are all so a lot of read me and help content it's only in German available right now because I'm using it for my students how they write unit tests or how they should write inheritance classes and something like that so this is also part of this project but not related to Jenkins and then you see here we have all these projects and you can open these projects as you normally do so this is the first thing we have in IntelliJ we have all sources here and what you need to notice is that all sources are currently bound to my or to tank but to the Jenkins repository that means not to your fork so if you want to change code and create a pull request you actually need to switch the remotes so I'm not showing it here how do you do do that so this is something yeah you will get it's not so complicated to change the remote so that we that you you need to press in GitHub fork the project and then you can yeah change the remote that means in IntelliJ we have the opportunity to debug the code so you can open everything yeah let's say our warnings oops warnings a little bit slow my computer let's see what the IntelliJ is finding actually it's finding nothing okay it's a little bit slow my computer I'm sorry about that it is a docker running in the background zoom is running in the background and the camera is running in the background so yeah pretty busy yeah it's quite busy now I'm it's getting a little bit noisy so let's see why it is not open I don't know okay so now the um our class is open so you can hear start development and one thing what students typically start with the development is they run unit tests and therefore I provided a setup of junit runners for the students that means if I press the run dialogue in IntelliJ you see that I have a lot of unit test runners preconfigured so for instance if you want to run the unit test of the analysis model project you simply select here and then you see here in the background the progress bar is starting then all unit tests are automatically started this helps in the beginning to see yeah where are the unit tests how do I start them so I already provided a runner in IntelliJ where you can use these where you can run these unit tests and so these yeah these runners are provided in the top most project that you showed correct yes this is I'm not sure if that's maybe we can have a look here so we have here an idea folder and we have some run configurations and here are all these run configurations stored okay great this makes it quite easy to enable code coverage how I would like to have it and yeah it's easier for students to start if already is preconfigured yeah I can get finicky to get them working yeah so I'll stop the test here right now and show you the additional runners I'm having I'm having a runners to run here all unit tests and I have yeah in the warnings plugin I split the unit tests in integration tests and unit tests because the integration tests are quite slow so we can have the unit tests which take only one or two minutes and we can start the integration tests separately which take I think 20 minutes so yeah you don't need to wait every time the next runner we have is I'm not sure how interesting is that for everybody all of my plugins have unit tests integration tests with unrunning Jenkins instance but no user interface and then we have also a user interface test using the acceptance test harness of Jenkins and these runners are also configured that means if I run these UI tests here from this runner then firefox window will pop up and the UI tests will be automatically started so yeah these UI tests I have one lecture which is about a UI testing in Jenkins and in this lecture we use these runners very often because we want to test in firefox and in chrome how yeah how we can start them and how they behave and now Uli have you found have you found that UI testing is successful for your students that they they find it productive and helpful using these kind of techniques yes I started with the acceptance test harness this was a little bit complicated because we have a separate project where we have these separate tests but now I've integrated the user interface tests into the plugin itself so these tests are part of the warnings plugin they are part of the git forensics plugin and in this semester we have some more tests for the code coverage plugin and for the j unit plugin the pull requests are currently pending for my reviews but they are provided for other plugins as well and this helps not only the students to learn how to make your high tests it also helps because I'm using these UI tests during the pull requests now so if someone provides a pull request for the warnings plugin for instance if Jenkins core is bumping one version again the next version then I'm running all my UI tests and I'm looking if my UI tests or my code still works with the latest Jenkins version for instance now that surprises me because there are many changes coming in the Jenkins UI even now have you had has that been particularly disruptive for you or are you able to adapt how was that how's your experience been there um the core changes still work everything is fine that's really good um the only thing is the acceptance just harness breaks what a broke so I'm using an older version of the acceptance test harness which is running fine but this is the nice concept of dependent bot in in a github so if there's a new version I'll automatically get a pull request which will be verified and currently the acceptance test pull request is broken but the Jenkins core pull requests are still okay I'm not sure if this will work again if we have this open pull request merge from the UI changes so I'm not really sure well the people are taking their breath here yeah thank you for the work you're doing on it thanks very much so maybe I'm not sure if we have time for the UI test to look into more into deeper maybe we can can come to it a little bit later so what I also want to show what helps my students is um yeah maybe I need to show the Jenkins part first um so we have a lot of uh runners here where you see Jenkins agent Jenkins controller build and deploy analysis model and and these runners are also useful but in order to show you what these runners are doing I need to introduce the next topic of my talk which is the actual Jenkins instance which I provided as well so um as already mentioned in the beginning um if you are using IntelliJS you can start the integration test your eye tests everything you can start but you actually want to see your code in action in your Jenkins instance so I created in this project one additional folder it's a docker folder and in this in this docker folder I have two docker files one docker file for the agent which is currently running Java 11 and the Jenkins controller these are quite simple docker files which have been provided I'm not sure mark you are one of the contributors and yeah I I used these files in my setup as well it is the latest Jenkins version with an alpine image and the agent is I think yeah a simple Java agent and this docker container when you are starting it let's head over or back to my scripts so if you are here on yeah we are already in the same analysis or in here's the same as warning step set up and here I already cloned the modules that are part of my setup and here we have a script to start this Jenkins which I'm using in my demonstration so you can well this Jenkins is configured with docker compose so you could start it with docker compose but it was required that I need to make a little bit more scripts around it so I'm using docker pull to get the latest LTS sorry I'm to get the latest version of Jenkins every time I'm starting it and then I'm using docker compose and yeah I need to set the user IDs correctly so because on my Mac somehow it doesn't work right well so just a simple script wrapper script around docker so if I start this script then Jenkins is starting that means I'm getting the latest Jenkins version then the build image is built so if you are doing this the first time it takes a little bit longer of course I already started that yesterday so now everything is fine and now Jenkins is starting and this Jenkins which is part of my environment has all plug-ins I am using typically in Jenkins that means there's a git plug-in the github plug-in and there are also these plug-ins I want to change the warnings plug-in the code coverage plug-ins so I think all plug-ins which are important and also some plug-ins which are not actually important in a good instance which I need some testing plug-ins with where I can use for UI testing or where I can develop some artifacts and it's very helpful because I noted students take a lot of time to install a Jenkins version then one thing is not happening then they forgot some plug-ins so here all plug-ins we need are pre-configured and you will see now when it's started it's a little bit unworking then we can see how this Jenkins instance behaves so Uli you've got the definition of this Jenkins instance inside that docker directory and it had all of the things that you need to define are there the the job definitions the everything everything so we have this docker file this is nothing special I'm just installing the plug-ins it's still the old script but it works so never change a running system and in this plug-ins all my plug-ins are defined which I'm using and I'm using Jenkins configuration as code to set up this plug-in this instance and yeah let's make it a little bit bigger so here yeah what I also need I need a connection to the agent because I already said I have a Jenkins instance with an agent which is the second docker image so this is also a simple Jenkins agent distribution and the only thing which is a little bit strange for everybody this is just I need to talk with the agent and the controller I need to open debug parts as we will see later on and therefore yeah we have some key cryptography which is not actually a cryptography because the key is public it's just in our develop setup so you won't use it in a real setup so everything is here in these docker files and when you start Jenkins then you get let's see if it's really still not here sorry it takes a little bit but this is a screen from a couple of hours ago and if you start this Jenkins then you have not only how is it called a job DSL plug-in I'm using the job DSL plug-in to get five jobs into this Jenkins and these five jobs are actually using my plug-ins again so I see these plugins in action so this Jenkins has these empty jobs now and now you can the students can press the play button on each of these jobs and start everything playing with experimenting with it yeah great there was a question and maybe just interrupt here this environment is a complete workbench with several plugins installed and the question asked by mark mark McCullough is that are there any optimization you can think within your process that focused on the single plug-in development explain a little bit what was the choice to have multiple environment and multiple plug-in environments rather than focusing on one single yeah plug-in the background is that in my research I'm using the static analysis and code coverage so one of my topics and these plug-ins depend on a lot of other plugins so in order to measure the code quality between my current change and the or in the pull request I need to make some delta computation so I need to make one build which is which I call the reference build and one build which is the actual build I'm inspecting the pull request and I want to see how many new warnings we have from this build to the reference build and in order to compute this reference build I need another plug-in and therefore all these elements I need in my daily work are part of this setup so if a student wants to improve the warnings plugin the student needs more than one plugin even the static analysis plugin is divided into two plugins the warnings plug-in which is let's say a Jenkins dependent and the analysis model plug-in which actually parses the warnings is independent of Jenkins because I'm also using it in a GitHub action without Jenkins so therefore I also need two projects and one comes after the other so I ended up in with 10 projects or I think it's seven projects now but if you want to set it up for different tool like Git you yeah maybe in Git you also if you want to develop the Git plugin you also need Git and client Git client plug-in and maybe some additional ones as well so I think Jenkins development if you're getting a little bit deeper it's not so simple that you just need one plug-in you need more than one plug-in and therefore I bundled a lot of them and not a lot but those that I need just a small question about the Docker installation that raised quite some interest how are you handling the required credentials using configuration as code or another yes it's configuration as code let's switch to the screen so I have these keys so basically the agent and the controller are talking using SSH and I encoded these keys here in the yaml file which is something you should never do in a productive environment but for here it's just fine and so here is the key and I'm setting up the agent with this key and this helps me to something which is very important when you are developing in this distributed environment I have a debugger port open for the controller and a debugger port opened for the agent that means if students change the code in Jenkins they can have this remote debugger attached and then they actually see the code stopping when the agent is hitting a breakpoint they see where they are actually in the code and they can inspect the agent running and the they can inspect the controller running and these are let's make it a little bit smaller so these runners I have shown in the beginning we have one agent remote debugger and one Jenkins controller remote debugger so when I start these runners they you see they are connected and they do nothing else so when I'm now looking at the user interface of Jenkins I can well I can yeah let's stop Jenkins here right in the middle and then you see okay where I am somewhere in the Jenkins controller and I can do the same thing for let's say one moment when I start the same runner on the agent then you can debug the agent code and typically my warnings plug in is running on the agent where the warnings are actually passed and then the elements are are put back to the controller and then I can see on the agent if everything is working and on the controller if everything is working so inside this single IntelliJ instance that you're running you've got it talking to a debugger on the agent and talking to a debugger on the controller so that if you hit a breakpoint in either location you get notified in your in IntelliJ yes that is fine and this is really important because otherwise you're always gasoline and I I see a lot of students are where can I put my sys out and why is my sys out not showing and yeah here you can have real debugging on the agent and on the controller yeah so you're showing your students how to do multi-process multi-computer debugging and diagnosis from inside the familiar world of their IDE nice it's very nice and the last thing which is here is also some convenience because I'm a little bit lazy so when you want to change your plugins you need to deploy these plugins to your Jenkins instance so it was a question that's interest Christoph about that so go ahead okay actually we deploy what I'm not you I must first say I'm not using Maven HPI run because this is not working as I need it so I'm deploying the plugins by building then on the command line and copying them into the docker container and then restarting the docker container so okay this is when you use one of these scripts it will done for you automatically so it basically is a script which goes on the console root calls Maven install then it has a delete the old plug in from the docker container copies the new plug into the docker container and restarts the docker container so it's simple but if you're doing it always on the command line you sometimes sorry I did not ask you I don't know you get bored or you do a typo and then yeah the very neat and very interesting procedure so let's see okay in the middle and now the the actual instance now finished it's starting so if we want to see the results then we can jump into these yeah projects and yeah it's still slow on my machine so you can have a look at the warnings plug in and typically you can also get now break points and if you want to have a break point yeah I did not prepare one because it's now a little bit late in the hour I think we need to keep a little bit focused on the time but you can debug everything by switching back to IntelliJ and and you see here the controller is still running the agent is still running so everything is under your control and it simplifies the development of such a complex infrastructure in Jenkins so basically everything I wanted to show so maybe we can have a little bit of focus on questions yeah there there's one question here from Martin a more general question which language do students use for plug-in development Java groovy the mixture we only use Java I'm not aware that anybody in the tank in the universe is using something different than Java because Java is just working and I think all plug-ins are using Java now now while you say Java there's a lot of JavaScript in the warnings next generation plug-in is that a complication for you how have you been able to deal with JavaScript and the Java world that the Jenkins involves I assume your students get involved in JavaScript also yes actually the user interface of the warnings plug-in the refreshment was made by a student and she created this in in her bachelor thesis and a lot of students are working on the front-end side in their companies where they are working besides the students besides and yeah I think it's still easy to add JavaScript on the individual pages of a plug-in it's a little bit more complicated if you want to show your new user interface in a page which is used by several plug-ins in tanks for instance the job view let's see so this view is totally under control of my plug-in so I'm using here bootstrap and I'm using e-charts and I'm using data tables here to use a different user interface as other plug-ins but when you get on the build page for instance this page yeah here it's a little bit more complicated and if you're getting to the top level view yeah now it's just one build though you see no trend charts but this page is subdivided by several plug-ins so it's a little bit more complicated to use JavaScript in here but in an ideal Jenkins world I would like to have these scripts I'm using in my plug-ins basically on top level of Jenkins so everybody can use bootstrap out of the box without configuring it a little bit strange currently I have one question about the VM yeah that you provide the students is that a hosted VM that they get to use or are they expected to have the hardware to be able to run that VM they have are expected to have the hardware on their own machines so we are using an Ansible script to create the virtual machine we are deploying the the image on our university cloud you know location and the students can get it from there but then they are they need to have a computer that runs virtual box or which yeah reamware or whatever what kind of specs do they need in order to be able to run this successfully run actually we use it it's just I think it's the I have four gigabyte of memory requirements for the virtual machine and one CPU and it is already working for them sometimes when they want to have UI tests with Jenkins and then we have Docker in Docker then it's getting complex and slow as you see on my machine today if you're running too many applications in parallel you need a new laptop now we we got a question in in chat related to is there a local versus server profile that you would consider for development when I see what you're doing it looks like you're doing what I think of a server profile anyway is there are there other things you might consider for cloud based agents or something or has has your development environment worked well even though many of your users are deploying to cloud or kubernetes environments actually both those parts I've never used yet even in my the other problem is that I'm now almost at 10 years in the university and I'm not in any business project anymore which is now using every different technology so actually I'm using it still in this old school let's say environment well but but have your you certainly have thousands of users of the warnings and g plug in there are thousands probably tens of thousands by now of users of that have you had cases where you've had to diagnose problems that were uniquely cloud centered or your environment has been able to let you diagnose any problem reports already okay yeah I think I can diagnose these projects with my setup but some problems just occur if they are in a cloud instance for instance the code coverage API transfers the source code from the agent to the controller which works quite well if you are have an agent which is right near your server instance and but if you are using it in a cloud instance it's really slow if you all transfer all your source code are highlighted but this is something yeah you actually don't need to have a setup to reproduce you can see the timings of the bug report and then you can think about it so my plugins are not so complicated that they need to use these complex setups thank you now do you envision that the setup you've got might be usable for someone who is beginning in google summer of code for instance maybe they're evaluating project ideas is this something that a relatively new person to the project could do or do they need to be one of your students in your classroom to in order to comprehend it well no this is I think this would be a quite an easy task for someone else for instance google summer of code so I think it's not really hard to understand what I've done here it's just a little a lot of work it was but now when it's now running you can just yeah it's kind of a search and replace you need to replace some modules and you need to make a maven module a maven multimodal but this is yeah not really complicated and now oh go ahead no sorry the only part which is a little bit more complex is the docker setup because it was a hard time to get it with the ports and the communication but that's working now you can inspect the controller on in intelligent as well the file content so yeah this is okay but the rest is I think simple so winding a little bit back to Darren's question one of the places we're considering is we're about to embark on the she code Africa contribute on and as part of that I'm worried that are if I told them hey you need to use this virtual machine is it going to be bigger than the machine that they've got available to host it so you said you run in a four dig virtual machine and that's enough yeah mostly yeah but um I always say to students it's it's better if you can run it on your own machine of course but then I'm it's it takes normally two weeks before it works on their own machine so it was easier for me to have this virtual machine which they are using in every other class so that's brilliant thank you thank you very much especially if you are using windows and docker you know it's hard it it's not always working as you wanted now wait a second those of us those of us who love windows that windows is my preferred platform I don't know what you're saying no sorry that's great well Uli thank you so much we're we're approaching our end time thank you thank you the recording that I'm looking forward to reviewing it again looking at your your docker definitions and you should expect change a poll request coming from me to think about how can I help contributors to things that I maintain use your technique several compliments to in the chat okay and if there are questions after the meeting I think we can use the community or the guitar channels how people would like to use great thank you Uli thank you Mark thanks so Mark thanks Darren and thank you everybody for joining us um we'll post the recording to the meet-up page shortly so thanks all and we'll see you next time bye bye