 Welcome, everyone, to the Platform Special Interest Group. Let's look at the agenda. I'm going to share my screen to show that. It's the Independence Day weekend in the United States, and so some of our US participants may not be here today. Here are the items that I have on our list for today. Oh, here I can do it this other way. There. So we'll talk about open action items. We had an option to have Natasha talk about the plugin installation manager tool in its latest iterations. Natasha is US based, so she may be out today. Windows installer status. Again, Alex will only be out today. Oleg, if you'd be willing, we'd love to hear a comment on progress with release drafter and how that's going. And then performance test framework. And I'm not sure that Abiodia is going to be here today. So Oleg, if there's something you want to report there, that would be great. Otherwise, we'll defer it to another time. Yeah, I think that we can just declare success and exclude it from agenda. Because, yeah, like we discussed at the last meeting, everything is in place. Even blog post was released by the time of the previous meeting. So basically, the part for performance test framework is done. We will be doing some improvements. But only on the ad hoc basis. So when we elect some features, the framework is fully completed. It's available. It's documented. So whoever is interested, you can just start using it. And there is a blog post for that. Great. Excellent. All right. So, and I'm going to put a to-do for me, because I really want this one, which is mark use the framework to compare, get client 2.8 and 3.0. In particular, we've got, oh, that was a mistake. In particular, we've got a major component change inside that, the JGIT upgrade. Excellent. All right, thank you. Yeah. And if you want, I can also summarize the work by Natasha. Oh, OK. Very good. Also, let's have you take that topic then, summary by Oleg. Yes. So basically, to summarize it, again, I'm going to put a link to the blog post. But generally, last week, we had JSO presentations that was a demo of the current state of the plugin installation manager tool. The tool has been released as alpha version. So if somebody wants, you can try it out. There are ongoing updates. But here, the first version is available for users. It basically replicates installed plugins as H from Docker. But here, there will be a more future study soon. Excellent. Thank you. Thanks very much. Then in terms of back to the open action items, I don't have anything to report other than that the action items that are listed as open remain open for me. I assume similar for you, Oleg. Yeah. Now I see you mentioning the configuration as code plugin. Is there anything here that we need to be discussing? I assume that it's sub-project work is ongoing. Nothing specific to platform just continues. Yeah, nothing specific to platform. So we do have some overlap, of course. But yeah, nothing really specific at the moment. Great. So I just added it to provide more context. Great. Thank you. Thanks very much. So since Alex isn't here, that would tend to lead us to skip the installer status. You willing to give us a current status on the release drafter? I know that we saw a pull request to the Jenkins repository itself, to the core repository. Yeah, I can show the current progress. Yeah, so if you let me share my screen, I can just show it quickly. You bet. You should be able to share now. OK. So one of the important updates is that currently release drafter as an experiment is considered as success. So if anybody is interested to try it out again, you can go and get some documentation. So the documentation is in the dot bit hub repository. And there is a file that released drafter.dog, which basically explains how to use it and how to get it applied. So this is all the documentation, where you can find the guidelines. I will just post to the link. But yeah, it's been adopted. So now we add something like 26 repositories. And these repositories include plugins, various core components, development tools, and also links. Yeah, you can find some examples here. But yeah, basically almost all active development tools have been already updated to release drafters. So for example, Jenkins Test Harness is here. And the release changes from the last week with the plugin compatibility test that has been also moved to release drafter. This repository didn't have release flow or release process at all for a while. But now you get some automated generated drafters. Well, you mentioned that there is quite a number of changes and more changes coming soon, but yeah. This is a use case of real release drafter application. There's a lot of changes generated. There's hyperlinks, there's machine and config contributors. And all these releases are basically generated just by configuration of several lines. The rest comes from the global configuration and the link I provided here describes how to use it. There were some initial questions with regard to permissions on repositories. If I enable this for the Git plugin, for instance, it's as simple as adding a release drafter.yaml to the .github directory on my repository, on the repository I maintain, and that's it. Not exactly, because you also need to enable release drafter. So we do not enable it for the entire organization. We enable it only for repositories we manage. And if somebody wants to add more repositories, there are two options. So if you're adminning your repository, you can just configure it in your own. If you're not adminning, you can create an infra ticket and we will get configured for you. But after that, you can proceed. So the consideration, you still need to keep in mind in security because the release drafter still requires full right access. So it means that the release drafter application will be able to, let's say, merge changes, push, quote, et cetera. Well, assuming there was any code to do that in this application. But yeah, from the security perspective, it's a decision to be made by mentors. So it's pretty alike. It depends about all the tools. You either trust it or you do not trust it. But yeah, we do want to enable it by default. But in the case of Git plugin, since you don't have continuous delivery in your repository, so yeah, even if release drafter integrates something, release drafter doesn't have permission to deploy the release to Jenkins or whatever. So yeah, for these repositories, we are not concerned at all. The concern comes from the repositories which have a kind of continuous delivery of production code base. For example, for plugin compatibility tester, yes, we have continuous delivery for Docker images here. But this is a development tool so basically we don't care much. But if it was production image, of course there would be more security considerations about that. Okay, yeah, another update which makes us to natural. Yeah, we had just another update this week. And apparently there was a case when the change logs go to the link. But we see Jenkins here, I take it for that. So the context behind that, that change logs which you can see here, Jenkins, I hear a change log. Basically maintained by me and Daniel. Daniel usually writes these change logs. If Daniel is not available, sometimes I do that. But yeah, this week and none of us was available. And on Monday none of us was available either due to some other stories. So basically this change log got delayed and we got a number of issues asking where is the change log, et cetera. This change log, it's not through this drafter, it's not regenerated automatically, it's managed manually. But yeah, we had a discussion with Daniel about what if he actually tried to automate something at least for draft purposes. So this change log is currently managed by both of us, Jenkins or Infra Jenkins. Here we can find for example, weekly, and just a second, weekly, you know. So this is a file which basically describes this change log. So the biggest advantage of this file that it's machine readable, at least the drafter is not machine readable per se because it generates markdown. But yeah, we would be still interested to have some release automation. And what I've done, I just made an experiment which actually configures released drafter to generate Jenkins-compatible YAMLs. So this is a pull request for that. Basically, it generates change logs like that. So it's fully compliant with the format being generated with the YAML. Daniel Beck has a script which generates drafters. And here, what I have done, I just hacked this drafter configuration to generate markdown, which includes YAML, which includes our change log. There are some details there. For example, two parts issue references and to put them to YAML, it was less trivial than just putting that because, well, there is no engine for that. You also do not generate type automatically. There are, I think it's created to release drafter in order to retrieve this information. But this generates some stops and currently it's in review and probably we will have it. And if we integrate that, maybe in addition to manage generated change logs, we will have something in GitHub releases, but mostly as preview. So it means that Huma was interested to be able to go there and to see this preview before we find it in this final version. So this is the idea behind that. Yeah, there will be some comments, for example, from Jesse, what if you just go all in the GitHub releases and do some integrations. So right now it's not in the scope of my prototype, but if somebody is interested to do that, you're welcome to do so. See, and I like the notion that what you're presenting is a draft that anyone can read in the repository at any time and then Daniel can paste it to the official change log and publish it when or you, whoever is running, acting in that role, gets to use it instead of the scripting that is already being used. So that seems very attractive. Thank you for doing that. So yeah, hopefully we will get it. So basically I'm waiting for feedback from Daniel about next steps because one of the ways is to actually, we could really generate these change logs in GitHub releases. We can then implement crawler which would take these change logs and get them to Genkisai also, but we are not expected to do something on Mondays or even more so on weekends. But yeah, so far it's just experiment. I'm not sure where it lands and whether it lands at all. Yeah, let's see. Yeah, thank you. I think it's elegant. So generating YAML from released draft or I assume that's not necessarily something that the original authors had envisioned. That's really cool. Yeah, right. So basically I created a ticket to make it more defined. So here, for example, you can see the tool mounting yet in Lucas is a maintainer of this drafter. So he already provided some feedback. So maybe we will have something like that, but it's yet to be defined. And here it looks like somebody experiments this change as well. Okay. Excellent. Yeah, so in the day or back, no me commit. So basically it's a copy place. So somebody just experiments with our stuff. I'm not sure who is it. Well, any experiments are much appreciated. I'm not sure. Is it even Jenkins or whatever? Okay, so yeah, this is something I hope to land eventually, yep. Full disclaimer, mine is work at all. Excellent. Thank you. Thanks very much. And I see that Alex Earl has joined us. Hello, Alex. Welcome. Yeah, how's it going? We had put a topic on the agenda and assumed it since it's independence today in the US that you might not join us. Great that you're here. I think we should switch to that topic now. And I'm gonna share my screen again so we can see the agenda. I think I've got the right one shared. Can everybody see the agenda? Yeah, I can. Great. So Oleg has provided us an update on plugin install manager and a performance test framework and just finished the discussion on our release drafter. Alex, your timing is perfect. You wanna give us a status report on the Windows installer. So I'm continuing to working with old block, I can't remember its real first name. Thank you on the infrastructure. It's kind of hard. He's on a very different time zone. So having direct contact, we're usually offset by quite a bit of time. It seems like we're just trying to get that, the trusted agent up and working and then I can start testing the framework build. The Windows agent, I should say. Great, thank you. Anything else that you wanted to share as an update there? It's not directly related to this, but I've started hacking on the Docker images or the agents as well as the Jenkins Docker image, but for Windows. That's currently not there. I've submitted two PRs so far for the JNLP agent and the normal agent images. They're kind of work in progress because there's no way to build them on CI.Jenkins right now. Oleg mentioned that Docker Hub may be a good place to do that for those. So I'll look at that. I'll also look at AppBear possibly. Although I think once we get the trusted CI Windows agent set up, it should be able to be used on CI.Jenkins as well. So that may alleviate that problem as well. Great, now I wasn't aware of Docker support inside the Jenkins infrastructure at all for Windows as an agent. So is there work that's happened elsewhere that's allowing that to actually succeed? So this isn't necessarily for agents on CI.Jenkins. There just been a request from a few people recently for Docker images for agents, but they can run within their own infrastructure. It's in line two by, yeah. Okay, so this would be Windows hosting the agent, the Docker agent and it would run, therefore running a Windows operating system, Windows in the agent. Yeah, Windows Docker can run both Linux and Windows containers, but this is a Windows container itself. Okay, I should say the right way. Thank you, that's cool because I could certainly benefit from that. There are plenty of cases where I need Windows on Docker for a certain set of plugins that I maintain. Yes, so for agent images, basically, once you feel that the product was good enough to be integrated and really integrated them. Because for agents, we have the Docker top part of the continuous delivery flow. So you can add whatever you want in your Docker files, in your scripts, you can put the delivery. Basically. I'll look into that and see what would be necessary for that from the, in terms of building these items. It looked when I, when I looked the other day, it didn't look like they had support for Windows containers yet. So that was, so it looked like app there may be the best reason for the Windows containers right now. Yeah, maybe, maybe there are the SACD services. So basically, Docker Hub doesn't work fast. You know, things like code fresh, maybe code ship or whatever. If any of them supports building Docker images for Windows, it would be easy. Okay. Cool, I'll take a look. Yeah, if it's up here, it's even better because we already have some components built on up here. So, found out. So the components we have on that there right now is that WinSxW? So yeah, Windows Service Rapper and Windows Post Management Library is built on up here because the agent is your, so there are two issues. The agent firstly doesn't provide enough Windows infrastructure. We need to test on multiple Windows versions which is not available. We need to Visual Studio of particular versions. It's also not available. So yeah, going forward with that here will demonstrate forward way for me. And the second problem that these projects are still not within JNPS organization on GitHub. They're within Kiki's personal repository. We had some discussions about moving them but we have never completed that. But yeah, so at some point we might want to move that and it would lock it. When I was talking to Tyler last time, he was strongly against the JNPCI for all components outside the JNPS organization. Even if JNPCS is one of the many consumers. I see. So is that, well, so needs more discussion, more investigation, sounds useful. That was very useful. Great. Anything else, Alex? No, that's all for me, thanks. Oh, like anything further from you? No, nothing specific. All right, I think we've reached the end of our session and thanks very much. Thank you. Have a great day. Thanks everybody. Yeah, thank you all. Bye.