 Hi, this is the Jenkins platform special interest group. It's the 4th of June 2020. Welcome everyone. Let's go ahead. I'm going to share my screen and let's look at the agenda to be sure that we've got all the topics we want to cover. So talking about open action items. Then Windows service wrapper for support Windows Windows service wrapper support for YAML parsing. Windows support policy Oleg. Then I'll give a brief summary of the get plug in performance Google summer of code project that Risham is working on. And if Slayton happens to join us will do custom Jenkins build service project I can talk to Docker images and Alpine briefly as a discussion topic. Any other topics you need to add to the agenda. I don't think so. Okay. Open action items the we are using the CDF zoom account now. So that's in progress, but needs a needs a pull request to show the place the new URL into the calendar. So calendar is not managed by pull requests. It's managed just by Google calendar. Calendar updated. I thought I had the good I will. Yeah, so maybe you're talking about Jenkins event calendar. But to be honest, I'm going to just use it and replaced by embedded calendar. Oh, I think that on Jenkins website. So are you okay if I leave it as is in that. So if you have referencing directly from the bottom six page, it makes sense to update that. But not for the recurrent events. I will just run the movies for you. Great. Okay. You are all in the platform platform page. If already there, I'm not sure if it's already there because I think I had intentionally not included it there. So that we didn't have it exposed that publicly. I've still got the open action item on a jet for Docker operating system support that continues a window support policy. Yeah, so windows support policy itself is done. We will talk about it later. There are some downstream action items for integrating changes, etc. But here we can say if you claim that this section item is finally done. And and it's merged everything set. Yes. So thank you. I still have the action item to review the Docker build rework PR. Alex and I were discussing it in addition in the context of Docker images and alpine. And so we'll talk about that later in this meeting as well. Windows server wrapper support for YAML. Would you like to give us a summary even just verbal is great a brief summary of where things are and I'll take notes. Okay, sure. Okay. Actually what I'm doing is. So previously Windows server is support for XML and what I'm doing in ing of 2020 is update Windows server for YAML support actually the configurations will be fitted with the YAML file and At the moment what I'm doing is actually I create a PR with the prototype with the support and I'm waiting for review for like and to continue with that. And and in the project also I'm going to do some documentation related to Sorry, Windows server and what I'm doing with the YAML supporting task and I'm sorry, but I don't know about poor things. I'm still getting used to using to Windows server. So So, yeah, those are the things I'm going to do in this meeting actually and yeah, that's all. I think so. Yeah, thanks for the update. So, yeah, maybe it also was mentioned that the restening request for XSD schema for some configurations, because you're right now Jinx project uses XML. So while YAML configuration is in progress. We could already get some business from this project once the scheme is landed. So, oh, like I'm not sure I captured that so the there's a pull request with the XML schema definition as well. Yeah, XSD. Oh, okay. But the XSD is just a standard XML. Great. Okay, thank you. Excellent. Brutica. Thanks very much. Anything else on Windows service wrapper. One thing which we will talk about later, we will be updating Windows service wrapper versions in the Jenkins core. So right now we use version 2.7 or even 2.5, which is a bit old. And there are new versions and this new versions include a particular useful features. For example, permission elevation when you install as a service. So you won't long we need to run agent GRS administrator in order to be able to install as Windows service. So, yeah, these changes will be landing soon. We're just waiting for Windows support policy because it requires some changes be landed. But yeah, this is what we will talk about later. It's great because I had somebody who was asking me personally, hey, how is the how is the install as an administrator so this will improve the experience for users as they as they attempt to install the agent process as a service. Yeah. Yeah, there are many other changes, but yeah, I would say that this is the biggest one. I wanted to actually landed last week, you today, you know, it's hot test. We had some delay in windows support policy discussions. So fun that I didn't. Excellent. That that is really encouraging. So is that one then that Boudica would end up creating a blog post on or a docs page change on it or is that something that would come from the Jenkins core team when when it's used. I guess that would come up from Jenkins core team, because it's not really related to Boudica's project. It's basically a result of a lot of changes by next term over the past few months. Some of these changes have been already integrated some are still need to be integrated. But yeah, once we get new version than the next releases will also include changes by Boudica so we're starting with. So it's just a foundation work, but it's really provides. I don't think there will be new documentation, but yeah, maybe some updates, because we already have documentation. The documentation is just flawed. So it may might be cleaned up and simplified. Okay, that's great. Wonderful. Thank you. So let's take Windows support policy. So, quick update, we already had a discussion in the last meeting about that. What has changed so that firstly, the policy was merged yesterday. So if you go to the Jenkins website now you can find it there. So that was a result of the yesterday's governance meeting where we approved some changes. So the notable change that we moved Windows 10 support from level one to level two, because right now we don't have means for testing of that. So Alex is looking into test automation, but for the time being, we agreed that it would be tier two and everybody is okay with that. So what it brings firstly, now we have an explicit list of versions we actually support so we can. Now we know which windows API versions we support, which is important for some of the projects. Let's say you include. JNA, we include the JNR in our libraries, and we have been already hit by updating and the suffering from a window API version some of the platforms. And pretty much the same for .NET, because right now, so what I was about talking that we bundle Windows Service Rapper for .NET Framework 2 and .NET Framework 2 is basically very old. And it became a maintenance burden and not all features are included. So this new policy increases minimal support version to .NET Framework 4. And then at the same time, if you need to use Windows Services, basically Windows Services is on the component depending on the .NET. You can use .NET Core versions built in Windows Service Rapper. So, yeah, for example, the YAML library Boudic is working on. Again, it has very limited support for .NET 2. So operating to .NET 4 will help us to enable YAML support. Great. That is wonderful news. Yeah, so YAML library doesn't need .NET for it can actually run with .NET 2, but there is a lot of limitations. So .NET is organized slightly different from Java. So if you want in Java, you can get the same, but yeah, there are restrictions work differently there. Well, is .NET 2 even maintained by Microsoft anymore? I mean, .NET 4 certainly is. No, it's not. .NET 4 is also obsolete. Oh, also, okay. Yeah, so the choice of .NET 4 basically comes from a minimal viable option. Let's say Windows 7, but we can bump it further later. So it's just temporary state. Most likely I will be suggesting to go to .NET 4.5 in a few months. Oh, okay. So previously when you were saying .NET 4, that was 4.0 or some? Yeah, 4.0. I see. Thank you. Yeah, so it's a .NET framework to be specific because .NET Core and .NET framework have different versioning. Yeah, so yeah, this is a minor thing, but at least it should improve our options to improve Windows 7's wrapper. So Windows 7's wrapper already provides distributions for modern .NET versions, but your .NET framework becomes a maintenance overhead there. Okay, so for instance .NET 4.5 already has a Windows W package available for it. Yeah, so the latest version right now is 4.6.1, for which packages are provided. We can provide newer versions, we can also provide .NET Core versions. So basically the packaging just defines the minimum required version of .NET. And for example, in Jenkins we have a lot of hugs to get .NET framework to versions running on modern .NET versions. And there is already a pull request from next turn which basically removes these hugs. So it will become a bit simpler and more testable. So you're all spent sometime this month to finalize these changes because they long covered you. Anything else on Windows support policy or Boudica, any questions from you to Oleg on Windows support policy? Actually I'm good. Okay. Great, thank you. Thanks very much. Okay, thank you. Next topic, brief summary on Git plug-in performance GSOC project. So the reshob has provided a benchmark pull request. And he's actually revised it several times working through the process of bringing JMH benchmark execution on to cident.jankins.io. So this gives us the benefit of having access eventually to S390X, PowerPC64, AMD64 Linux, and Windows AMD64. Potentially. So the problem with it is that cident.jankins.io is still not designed for benchmarking. So I had this discussion last year as a part of JSOC, as a part of platform seek meetings. But on demand provision and call for virtual machines and containers. It's not exactly how you do performance testing if you want to get metrics. So yeah, if you improve performance by 10 times, it's one story. But if you improve it by 5%, then our current infrastructure actually isn't able to reliably capture that. And that I think right now, given that this is the initial exercises are actually comparative checks between CLI Git and JGit. I think the risk is relatively low there. The agreed wholeheartedly. Yeah, there was no risk. You just shouldn't use this metrics as absolute values. Relative ones. Yeah, for sure. Yeah, so the risk is benchmark comparisons between between runs are ultimately unpredictable because we're getting on demand provisioning. One of the things I did see is that the pipeline library seems to use a resource lock, which attempts to prevent more than one performance benchmark from running at a time as though it were locking onto specific class of hardware. I haven't investigated yet though. So there is a library method and there is a blog post from a view there. It was just a student in 2019 working on the performance for all strategy plugin. So pipeline library step uses high mem machines. So basically the machines we are using for acceptance this harness. And yet these machines, I believe they still provision as virtual machines most likely still on Asia. But still, these machines are not that predictable in terms of performance in terms of, especially if it comes to network overhead. So, but yeah, it's definitely better than running with ACI. Yeah, and they understood there. Okay, so between runs between jobs. Yeah, they get a different machine. So one of the one of the techniques we've also been using has been to run the same benchmarks on mark CI server, which has fixed hardware but it's ancient fixed but old hardware. So it tells us something different. The other is that he's running his on. His job is running on his Mac. So we're, we're seeing interesting samples and doing being able to cross check between various configurations and say hey, is it consistent that on small repositories. In fact, faster than CLI get and is it consistent that on very large repositories CLI get is dramatically faster than J get. So, those kinds of comparison. What's that until you run out of memory. Because J gate is much more resource consuming than. Right. Well, even even ignoring the, the resource consumption we've seen that with large repositories command line get wins every time. Even if J get has lots of memory available it's still fundamentally slower than command line get is command line get seems to to somewhere between the 10 megabyte repository and the 90 megabyte repository. So J get loses the race. Maybe J get may have some advantages for cases where we cannot use a common language. For example, if you want to fetch a particular file using to get. For example, with J get you have opportunities to shortcut particular needs in order to, for example, query the Jenkins file from repository. Okay, in the most cases, I think you should just use proper provisioning of like GitHub branch source or whatever. You should do it without any J get magic. The benefit there is get the branch sources can then use the rest API, they can, they can make direct requests to a single file. Yeah. So, that continues. The, we also have two or three pull requests pending several pull requests already submitted. One is for the redundant fetch removal. One is for is to refine and improve the benchmarks. One thing I have to drop. I just got an emergency meeting request. Okay. So, sorry for the late notice. Next time you should just have a full meeting with more participants. Thanks all legs. Bye. So last topic was Docker images and Alpine. And there Alex Earl, the maintainers of the Alpine images, Alex Earl, myself, and how awkward, one of the person met last oh and like met last week, and discussed, how do we approach the dot the Alpine images right now we need to update the Java on Alpine, because it's currently JDK eight update 212. It's therefore several several major revisions behind or several revisions behind the current, the current Java eight update 252. That is in progress. Alex has submitted a pull request. And the, the change really will have to use adopt out of open JDK. Instead of using JDK, the open JDK bundled with Alpine because Alpine no longer provides JDK updates beyond 212 for Alpine three nine so that that part of that transition will be adopting adopt open JDK. We also expected that we will eventually update our Alpine base operating system version to three dot 11 or newer. Those are the items that we had for our meeting today. Butika unless you have others I'm going to go ahead and stop the recording and close the meeting. Okay, okay. Thanks very much. Thank you for joining. Thank you.