 on this computer. It says we are now recording. Thanks everyone and welcome to the Jenkins Platform Special Interest Group meeting. I'm going to share my screen and let's look at the agenda together. All right so what you'll see here is is the the agenda for today. As an agenda review we'll talk about open action items first, then Java 11 status check, Google Summer of Code with Natasha. I'm sure I'm butchering it and Oleg talked about Google Summer of Code. I apologize. I will yet get it. I don't know that we will get to YAML configurations. I'm not sure the people we need but we also want to allow time for a presentation and custom warpackager from Oleg. Any other topics we need to put into the agenda. Okay I'll take that as no. So past action items we've still got the to-do for me to submit the JEP for a Docker operating system support. Sorry it hasn't happened yet. Oleg I think the JEP for Windows support policy is also open. Oh right sorry yes the action item remains great okay and on the code signing infrastructure as far as I understand it Olivier has been been at least discussing with Alex but no further progress that I'm aware of. Yes it's in progress and it depends on code automation. So once we have code automation for it would be one of the next steps. Great all right okay so so is it okay if I note that that depends on what depends on core release automation project. Yeah we had a discussion about that on Tuesday at the infrastructure meeting. Okay excellent thank you. Hello. Hi Baptiste. Sorry to be late. Thank you for being here. So then on the community bridge project Oleg anything you want to report there. We had a discussion about community bridge just one hour before at the advocacy meeting. So generally I presented what we have there and we have interest from other folks to get it running and my plan is to have a number of sample projects supported there some for documentation and some for other topics. So if anybody is interested to post a project idea there I'm ready to press it because I already just set up a test account and we can do it now. Great so the docs could submit things into that community bridging account with your yeah right and we are going to discuss it tomorrow but yeah generally we can do that. Excellent thank you. I'm not sure whether Alex is joining today but if he does community bridge is also an option we can press it please. Great thanks very much. Next topic then Oleg do you want to lead out on a discussion on Java 11? Do you want should we have others take it? So Baptiste do you want to do that or would you press me to do that? Oh it don't feel strongly so the point today was I mean I couldn't do it you I would be letting you rest a bit because you're already leading a lot of things. So I think what we wanted to say today is kind of clarify slash visualize even more even so the Java 11 support for Jenkins is now considered done. We've been publishing as far as I remember now two months ago I think a blog entry article on the Jenkins.io website celebrating the Java 11 support on Jenkins so and last was it Monday already so four days ago we finally actually migrated the ci.genkins.io instance to Java 11 runtime so given this we considered so for people watching there was a Java Jenkins announcement proposal a JEP 211 I think was on the bottom yeah so JEP 211 was about you know that initiative and I think we can declare I think the final step which is basically getting back to normal flow and entering the usual flow like people reporting bugs and we fix them so because because since we've deployed and announced that since the last even the preview in December last December or mid-December we didn't see outstanding bugs really unfixable or concerning the other one really was I think of around laxity which is considered a fixed issue right now and so yeah bottom line Java 11 support is ready we are closing the outstanding project around that sorry I was distracted a bit by the noise but that's surprising because I'm Jerry doing a lot of noise so we can consider the Java 11 support initiative Jenkins done and we are back into normal maintenance mode right I did it sorry yeah just throw it some context today as a part of JEP 211 we had post-release support period by java 11 support team basically I'm on our own again and the several other folks support since the first LTAs release so basically it's completed now and all other parts of the project have been completed so we have test automation so I think it's it's actually mark working and so you're you're doing a great job writing notes mark but I think there's an issue with your mic and the mic is like probably just on the keyboard or something like this yes sorry about that so let me let me I fear that we'll just have to have somebody else take notes my keyboard is obviously too noisy for the meeting sorry I was about saying that I will be making notes but then I realized this is not going to be any better so so I will I will periodically mute and unmute myself so that so that I can take notes as people are talking thanks very much by the way I think this is such a point of pride for us we should be so delighted with the results of Java 11 in this project what an amazing thing you've done as a team thank you very much thank you mark and main props go to like I would say because he's been going to work pretty amazing amount thank you I wouldn't be able to do it alone for sure so yeah we had something like 50 contributors the announcement post so yeah it's was actually a huge project for the Jenkins community yeah congratulations so Natasha why I think you're the next one unless there's anything else on Java 11 I think you're the next one for our discussion topic okay um good morning everyone um so yeah I've been I've started um my google summer of code project so last week we had kind of tried to look at you know what it would take to I guess like pull the plugin manager out from core which is obviously very difficult and I think probably too much for this project right now but um so I've kind of switched gears a little bit um and right now I'm working on converting the install plugin uh bash script to Java so I have a repository I can send you and we're so kind of in the process of moving that so you don't need to make links but if you want to screen share in order to show something feel free to do so yeah sure um okay sorry I'm still figuring out how to use zoom so so we're not to screen share if you want to do so uh mark should stop screen share and then you will have a share button activated in the bottom okay okay okay how do I stop sharing or like I'm sure there's a control somewhere on the top there is a screen share status bar or something like that so basically you need to click stop there I see the meeting controls now oh there it is got it stop share found it thank you the time you're not the only ones still learning zoom clearly okay great uh okay um so can everyone see that you did it okay okay great uh so uh yep so I don't have like a a demo or anything yet but um basically um this is the repository um and I'm kind of in the process of uh moving it from mine so I had some questions about that I don't know if this is if we should do that now or if we if you guys want to continue with the meeting and then I can maybe uh sync up with somebody after and um they can help me finish moving everything so yeah uh yeah so I guess that's like all I wanted to share I don't know if anyone has any questions or um input or anything actually that's that go ahead or like yeah I just wanted to reiterate it about about the community value of this project because yeah we have a lot of problems related to plugin management in jacquus components especially once in the scope of this seek for example docket packaging and it would be really interesting to have these projects so that we can streamline plugin management across components and maybe get some edit value features so this is where it comes from and there is already a lot of interest stakeholders for example jenkins configuration is called plugin folks they are also interested to have this tool because yeah use some architectural issues managing plugins from the plugin site isn't possible so there is a lot of stories for sim yeah a lot of synergy opportunities for projects inside jenkins okay all right I'm gonna stop sharing so you can have control back mark you are mute mark thank you I was talking very well and no one was hearing if I shout loud enough will you hear me across the ocean so next is performance testing for jenkins plugins right um I just saw my screen just once and now that means I have to again figure out how to stop sharing we are first seeing you to get through that process so that it becomes natural I'm sure I will eventually get very talented at doing that yeah you know that's the balance the thing about continuous delivery you know if a release is painful you know every month do it and then it will become just not painful okay so is my screen visible yes okay so I am working on a benchmarking framework for jenkins using java micro benchmark harness for my google summer of code project so what is so let me just start by what is java micro benchmark harness yeah it's it's an open JDK project which is used to create benchmarks um for languages on the jvm so what it basically does is it starts up some warm-up iterations just to avoid um compilation do machine language code um when it when the benchmark is run and after that um it runs the actual measurement um iterations so it allows us to measure the um benchmark results in multiple ways like average time the number of operations per second and single short time the time to um just do one iteration without warm-up and multiple other things which are there um which you can see on the docs um so what it basically does is it runs multiple folks of the jvm um so that's running the entire process multiple times um so we reduce the measurement error now so how does this framework work so um it starts from your normal j unit tests um so all the classes uh which are annotated by jmh benchmark can be automatically found and according to your um and for the benchmark each folk of the benchmark a temporary instance is started now um you can either configure the instance using normal java code or you can use configuration as code um both of these strategies um can be seen in the role strategy plugin right now so this is how a typical benchmark looks looks like so what we have um we uh in java macro benchmark harness um to pass information to a running benchmark uh the only way possible to do is to have a state class uh this state class is automatically instantiated during the benchmark runtime uh by jmh so for us we have two methods one of them is the setup method and the other is the tear down method so uh for both of them uh they can be used to set up your resources and your instance uh and do whatever you feel like for your benchmark and so then your benchmark methods have to be annotated by benchmark to be found by java macro benchmark harness and your benchmark code goes there now we can also use configuration as code it's the same thing uh instead of the jmh benchmark state here you have to override the uh configuration as code java macro benchmark harness benchmark state so the only thing here is that you have to provide a part to your configuration file um so when the instance is started it is automatically configured with using configuration as code and you can run your benchmark here now so the benchmark reports can be analyzed directly from your j unit tests um it returns a java object which you can analyze to either pass or fail the test and you can have multiple things to be measured during one benchmark the reports can be written to your disk and they can also be archived like we would be doing on a ci jenkins instances um uh we would be taking json reports so these json reports can uh be either used by the jmh report plugin for Jenkins or they can be used on the jmh visualizer website i'll show an example later um yeah so this is what a sample of the visualized report looks like now some challenges and bugs which are present here um one of them is the test crumb issuer which was refused to be marshaled uh from configuration as code that's jb 200 and the other thing is when the benchmark completes uh the jetty server leaves straight threads which causes um the benchmark to run for 30 seconds so jmh waits for the instance to come uh to cleanly exit but it doesn't so it forcefully kills it after 30 seconds now um these are all of my pull requests uh i am now moving the code from the role strategy plugin to the Jenkins test harness so it's available for everyone to use and thanks cool that is awesome wow okay so micro harness any questions from the attendees that was absolutely wonderful i think that's that's great yeah so i don't look actually at the prs on different plugins are there are there about um basically showing how to use it on the virus plugins on on generating benchmarks marks on various tests so i'm sorry to be asking dummy questions but i don't look at those pr actually so uh we have some sample benchmarks in the role strategy plugin i'll show them here and after you've shown that is there is there a way for me to or is is the use of external processes like for instance command line get a threat to the accuracy of the benchmarks or can the micro benchmark harness actually operate even with having processes forked and depending on the results from those processes uh so what it basically does is it creates a fork after a benchmark has completed so when multiple folks are on it um it basically eliminates the possibility for other processes to affect the benchmark results because we're taking so many iterations it wouldn't actually matter ah okay so it's a multi it runs multiple executions of the exact same test together a representative approximation of the actual performance thank you yeah probably it's not main slightly interest yeah i just got confused talk sorry so let's just show you a benchmark possibly using configuration as code so what we do here is um first we actually verify during the set of that the instance is actually correctly configured and then after that um here what we do is for each thread so um jmh trans multiple threads um again to ensure the correctness of the results and what we do here um this is something related to the whole strategy plugin and we generate acl objects and we benchmark the time it takes yeah you can see that the initialization uh so in Jenkins we use a threat local storage in order to keep out notification so he gets uh initialized one on the threat uh start up by notation above thank you thank you great thanks thanks very much okay thanks everyone thanks for like a set thanks for seeing this marvelous demo yeah thank you and yeah hopefully at some point we will get to the stage when uh it's available as a part of Jenkins test harness so any plugin user can just use it from there right thank you thanks very much up you do yeah i'm sorry about my poor pronunciation of your name i will keep trying i will yet get it oh like i believe the next topic since we're not likely to talk yaml's configurations or the next topic we'd configure a custom warpackager rather than if you over sharing do you want to talk to that or yeah i can uh but i'm gonna present that so yeah i think that uh no one more about customer packages could be useful for the special interest group and it could be useful for Natasha because uh it also has its own implementation for plugin management so i'll probably just share my screen and show it to you and do you see my screen okay yes no we okay so yeah i'll just open one of my slide decks you're only going to go through the entire slide deck right yes but yeah okay so basically what's the problem uh is Jenkins configuration management another thing that yeah there are too many options for example you can use jcask plugin you can use groovy hooks in order to initialize the configuration you can install plugins using plugins team docket or by applying various configuration management tools it's definitely doable but it takes a lot of time to configure the stuff and to maintain the stuff and one of the questions so could we have something different uh because uh instead of having a lot of tools we would have a single tool which it just takes everything and packages it as a ready to fly configuration so basically it's what a custom warpackager is about uh historically it started as a test automation tool for Jenkins because some of our test frameworks like acceptance test harness and plugin compatibility test that then they rely on a word files as input and we needed to run these tests in special environments for example if you want to test an artifact manager has three plugins you need to run in aws and in order to do that you need to configure the plugin and then you need to run an existing pct test so this custom warpackager we were just able to produce a word file which has all this kind of self-configuration out of the box and which produces ready to fly images so it takes a configuration yaml which defines which code to take which plugins to take which configurations to pass uh then a custom warpackager is a tool just that's the packaging and it can produce three outputs uh do you see the screen on the right uh i mean here okay so custom warpackager can produce three types of outputs firstly it's Jenkins word files then it's Jenkins docker images which are compatible with official Jenkins docker images and also Jenkins file runner images uh based on the same configuration and what happens next yeah you can specify what you want to take and then everything just gets packaged and you get this image so it sounds pretty simple and yeah probably i'll just show a couple of demos okay demo okay let's take a look at cask demo okay cask is configuration stored okay okay so this is the entire demo and we have a packaged config yaml file this yaml file defines what you want to get from Jenkins so there are some metadata like bundle there are build settings which define which docker image we take as a base when we package a docker image then we pass a word file for Jenkins we pass a list of plugins and we pass system properties and the Jenkins configuration is called yaml in addition to that you can pass groovy hooks and if you want you don't necessarily have to pass release sessions because customer package it also supports the building the plugins on the flight from branches you also kind of write libraries you can rebuild Jenkins core for example if you want to test this new Jenkins promoting question there are tweaks which allow to pass them i am not showing them here but yeah all the features are in place and they recommend it in a plug in customer package with me but yeah this is a pretty simple configuration the only thing which doesn't come in this yaml is another yaml for configuration is called but for this particular demo it's pretty straightforward well it's just a bunch of configurations for example system message some basic security setup role strategy plugin configuration so similar to what we have in performance tests when we configure role strategy yeah this is ownership based security and then if you want to get this image running you just go to the instance okay make files just my own production but what it does here make file actually takes a customer package at scli tool so currently customer packages supports scli tool and it also supports maven plugin so if you want you can use custom work packages as a part of the maven flow also we offer official docker images for customer packages where you can build Jenkins inside obviously you can't get a docker image today because it would be docker and docker but it can produce your source configuration and then you can just go docker build inside and then when you're ready so the image is just produced here and then you get the output so we have time to directory customer packages is ryan but basically what it does actually it's an elegant wrapper on the top of various maven plugins and various tools for example here's a packaging state and you may see that customer packages just generates Jenkins bundle using maven and then it uses maven hba plugin this custom work in order to just build the bundle but then it takes this bundle again because we use this bundle and we inject jcask scripts or groovy hook scripts directly into the image and the same we also can overwrite system properties for example yeah here we have the built image so you may see that yeah Jenkins yaml d is just injected the work file we also modify for example web xml because we take web xml and if you're scrolling the bottom you may see that yeah it's not format at well but what we do here is we just add additional xml entries for the right setup method so we want to skip it to inject it directly and when Jenkins starts up you get this configuration applied automatically so here it's still building customer packages isn't very famous for quick builds but yeah eventually it should produce something so let's take a look what actually my demo does make file oh i run docker image there yeah so then if i run docker image so let's assume it builds successfully and then i can just run my ground command yeah oops yeah it's not going to work in that way because i have written a proper make file so okay i think it's not something we really need to go through but yeah finally once it completes it produces you a work file or docker image or Jenkins file runner with all the configurations so you just get it running okay this demo has no chance to compete in foreseeable future period because i wipe everything and when i ask questions oh my have issues with pretty much everything but yeah for example i can show you a demo of Jenkins file runner we have so jfr we have a demo called Jenkins we have Jenkins file runner so Jenkins file runner can be also packaged by configurations code and here what you can do is just make run so again there is just a configuration packaged by customer packages but actually uses Jenkins file runner and in this demo we use some plugins like pipeline rigidity steps which gets a configuration and passes it to the instance yeah my docker is extremely slow right now oh like what to be sure that the Jenkins file runner concept was one that i hadn't caught on to initially it is that in order to execute a single pipeline this has the elegance of it will start a a complete Jenkins run the pipeline and then tear down the Jenkins so it starts a lightweight Jenkins executes my little pipeline and then exits again yeah exactly so yeah you can see basically it happening here because once customer packages builds the image we just execute a docker container and this docker container takes our pipeline and just executes it here so yeah we have probably i'll just open the configuration as code yeah so basically the source code for my demo is just a customer packages config pretty much same as before it takes a number of plugins packages to them it doesn't really need configuration as code here so we don't pass configurations but here we take a Jenkins file runner we build it here and then we pass Jenkins file and here you may see the for example that we use pipeline rigidity steps plugin which is not included in the Jenkins by default but yeah this customer packages will be later ready to apply instance where all the plugins are embedded hence you can execute this pipeline out of the box and if we go through that we have yeah so if you're interested to know more about Jenkins file runner then i have a slide deck about under the hood of several Jenkins Jenkins file runner and there is a recording from cognitive special interest group where i was presenting this tool but what might be interested to the platform seek and for whomever developing Jenkins pipelines and pipeline libraries there is a project called CI Jenkins IOR runner basically this project is an emulation of CI Jenkins IOR in Jenkins file runner mode and it supports commands like building plugin so for example one of the demos in this project is just building a local plugin it is effort of local plugin source codes but yeah there is no magic here we just build plugin and Jenkins file runner can really execute this demo and it can execute this demo like it was doing in CI Jenkins IOR so pipeline libraries support that a lot of Jenkins plugins is included like find box plugin and whatever and you can run this demo in order to really verify results and to test pipeline library a lot before you submit a pull request because yeah for Jenkins project we have this issue is Jenkins in for Jenkins IOR sorry pipeline library so yeah we have pretty complicated pipeline library which we use for all projects inside the Jenkins optimization so Natasha and Amida you will be also using this pipeline library for your automation ideas and here we have steps like build the new whatever but we have a technical depth in our project so we don't really have any kind of test automation or continuous integration that is liberal for this library so that's why I developed some packages so that I was able to build and test the components locally and then yeah probably we'll spend some time on integrating on offering continuous integration for pipeline library here maybe using Jenkins file runner or other tools available in the project now but yeah CI Jenkins IOR is something you could try if you want to see how custom work packages works for real use cases because the packages the entire CI Jenkins IOR is pre-configuration and it packages it ready to fly down okay so Oleg on ci.jankens.io I'm accustomed to having windows machines always available how does how does this operate in a context where it needs additional agents with special capabilities okay so are there two answers for that are you able to connect agents from Jenkins file runner of course you can for example SSH slaves plug-in etc so you can connect them moreover Jenkins will be just showing them about having side card containers in Jenkins file runner but these them depends on a food request which haven't been integrated yet remotely so yeah there is a food request which would enable connecting Jenkins to headless Jenkins masters because our current problem that in order to connect genlp agent you need to have a web interface available and Jenkins file runner obviously doesn't do that so there are two work arounds firstly is for example Apache Kafka Plamene which is currently under development there is a project by law in order to make it Kubernetes friendly in google summer of course but yeah also you can use SSH slaves and other launchers types in order to connect so yeah this is just one of the ways but how do I do it in my case in my case I just updated pipeline library to be honest because I assumed that for me the most straightforward way is to support the filtering of components so here minimal purchase for Jenkins file runner support and here what I do is so here I just check some system properties and if we take a look at this Jenkins Iurano to this system properties just said by custom work packages and they injected into Docker images so each time we run we just skip windows builds because yeah pipeline library skip windows well it's probably not an elegant approach but it works but yeah good news that for Jenkins file runner we actually see a Jenkins Iurano support was java 8 and java 11 at least so yeah you can test java 11 pipelines inside it as well excellent well and I've used SSH agents with windows machines already so just the fact that you support SSH agents allows me to run I think just like it's another agent that's cool elegant very elegant yeah right so it might be a provisioning time but yeah SSH slaves can be configured via Jenkins configurational scope so on stuff that Jenkins will start starting up these agents your job pipeline starts in parallel then depending on the state it will either wait for an agent to be available or starts to be built immediately but yeah if everything works well then you will get it executed to an external agent and obviously it's companies your responsibility to ensure that the multiple Jenkins file runner instances don't collide with each other right right so as they as they consume they need to somehow make themselves unique yeah yeah right so it's not a problem of Jenkins file runner it's a problem of top level infrastructure right so we are back to customer packages yeah basically we had a blog post there is a lot of demos in the requisitoring so if somebody is interested you can just take a look what hurts there is of course plugin management because in Jenkins file runner itself sorry in customer packages itself plugin management is pretty weak and yeah you cannot define it in YAML but basically in all my demos I switched from YAMLs to POMXML definitions so here for example see a Jenkins file runner I define plugins from POMXML why I needed because I want to have dependable enabled so managing dependencies in Jenkins file runner well it takes a lot of time so I spent some time automating that and here you may see that there is dependable enabled you have go into variation in the Jenkins community and it dependable just amidst pull request and then once CI passes for CI we have Jenkins file runner test harness framework created by Everest and Transistor when you work in Jenkins file runner and yeah basically all these patches get verified and then they get integrated so yeah I use POMXML in order to declare dependencies and I also use POMXML because customer packages implementation of plugin management doesn't support the upper bound solution so it means that if there is a transient dependency I cannot guarantee that the proper version gets injected by customer packages so instead of that I use plugin POM because plugin POM ensures that so I just used Jenkins development tools in order to verify that the plugins are compatible but once we have plugin manager on the CLI tool probably I would be able to get rid of that and use this tool in order to verify compatibility of the plugins and maybe get some extra features like but security checks or whatever okay any questions none from me thank you very much Oleg yeah so if you want to try it out just take a look at the repository and yeah another use case which we might consider again for plugin manager tool that actually customer packages allows a variety of Jenkins code versions for example here it's a bit obsolete implementation for that but it doesn't even include YAML here it includes YAML here I believe yeah so here I actually use customer packages in order to patch libraries and what it means that if you had a library for plugin manager you could just inject it in the Jenkins code using this tweak and customer packages would create us an additional instance with embedded libraries and then we will be able to do plugin management from Jenkins using plugin manager tool well until it's just included into the code directory if it happens it would be cool if not customer packages as I work around Oleg in this example you're listing a source location are we are you building from source or no you're grabbing the artifact by do you're actually building from source yeah so customer packages supports that it can build from source it can take a release version it can take a incrementals version why I need it from source here because it's a demo of all latest all latest so basically it's a bleeding page demo and I assure you it's it bleeds a lot but yeah you can use it in order to build Jenkins from all the recent components yeah so yeah for example awesome etc there you go some hugs with that so basically this demo needs to be rewritten because I have a newer implementation in customer packages which is actually based on Jenkins properties so here we just uh replace patches this week patches but there is also a way to just build the component and inject it the version of system properties so for example for the modem version for stepter version we could use a list approach instead it's just another demo but yeah yeah cool wow that is brilliant thank you yeah so that's why the blog post was called build your own Jenkins or something like that because yeah basically it's what you can do there thanks very much Oleg that that is an amazing piece of technology thank you so in terms of our neck are there any additional comments you wanted to make with regard to alignment with the platform seg I know you'd mentioned for Natasha how this this might be of help to are there others I can see how the technique can help me and my validation of the get plugin for instance so so you've inspired me to try it yeah so regarding validation of get plugin I can show you something because yeah customer package isn't just a single tool be as I said in the beginning we created it for test automation so if you go to pipeline library there is a library step created by Raul Raul is a maintainer of plugin compatibility tester and is also an active contributor so there is a step called essentials test historically it comes from Jenkins assertions which later became a Jenkins evergreen but effectively it's a tool which allows doing integration testing and what it does here it can package a custom work using a custom work packages for example take custom versions of plugins custom configurations and then you can run this package through acceptance test harness and through plug-in compatibility tester so using customer package and using this pipeline library step for example you can use it this library method for deep plugin and verify it against let's say github branch source plugin source code so you can run the github branch source test suite with your new underdeveloped version of deep plugin and you can get results so that well at least nothing breaks and using plug-in compatibility tester and same for acceptance test harness which is rather than getting UI tests right now excellent thank you so so I assume custom work package or the results also give me something that I could execute does it have a presentable UI as well it does doesn't it if I wanted to look at it and explore with it while it's running or does it's does it exit immediately after after startup are we talking about uh plug-in compatibility tester or about a customer package custom work package or package it is entirely cli tool but it can reduce jenkins work files which just increment standard jenkins work files with web interface etc so you get standard jenkins work file which you can use or standard docker image or jenkins file runner if you don't run everything of it regarding potential synergy for example if you talk about benchmarking yeah for example we this essential test and we could also use it for benchmarking purposes because yeah we run plug-in compatibility tester here and plug-in compatibility tester inside it actually runs jenkins test harness so for example when a media finishes migration of frameworks when we have some automation tests we could probably do the same in order to do some performance tests as a part of our integration test and if you want so yeah custom work package could be used for that as well but if the kind of moonshot but yeah why not so basically what we would need to do that is present conditional profile which you can pass through metadata is minus the benchmark I believe and the one to pass that benchmark test would be also executed for plug-in compatibility tester okay thank you thanks very much and oh like that I believe it was our last topic on the agenda if there are no other topics I would propose that we call an end are there other topics that need to be discussed in the meeting not from myself all right thanks everyone I will archive a copy of the of the video and we'll post it also next meeting will be in two weeks same time thanks very very much yeah I'll try to get to do with us on the next meeting because we have open story about multi-architecture docker images and I'm not sure whether what how to press it there well and I will talk with Alex Earl because now that he is in usually the U.S. school year has ended by now he may actually be available in two weeks yeah right yeah it's also something so when we switched from Java 11 to plug-in installation tool I wanted to add that yeah actually installers you're not going to put it in the JEP 211 scope so it means that although we applied some packages for example for Debian packaging etc. Minus installation manager so the MSI installer is still somewhere on our plate and we need to do something about that in the future great thank you thanks everyone okay thank you all okay thanks thanks everyone