 Click the button. All right, welcome to the day four sync up everyone. We are taking questions for anyone watching on the IRC channel, Jenkins Hackhouse, or on the Gitter channel for Jenkins, CI Jenkins. Well, it has an update for us. Yeah, I have just a second to think in other participants in the chat. But yeah, we have some updates. And actually, today is just a sync up session. I'll share my screen, and we just do the stuff. Yeah. OK, so do you see the matrix? Yes, now yes. Yeah, so I would propose to discuss agenda today because we had several requests for discussion. So it's day four sync up, by the way. I would propose to just do stuff updates. Then we had a question from trace about Java 10 support page. Then we had a question about upstreaming core changes. So what we can upstream to if it releases from now. And then the rest is we want to talk a bit about testing plugins with Java 10. So I would propose the following quarter of the agenda. But we can adjust if you prefer. Go with it. Do we have any other topics to discuss today? That's enough. OK, then let's just do updates. So if everybody is interested, we have a big Jenkins and Java 10 hackathon document which includes everything. And here we have a session for what's happening now. And I think we can just proceed with this section. So do we have some online? Yes, sir, I'm here. Cool. Oh, tell us what's going on. I'm still trying to get to the bottom of the compilation issues. It's definitely deep in the stack. If not Java compiler itself, something with the Maven compiler, which I'm going through the sources up now. I had a possible lead from Jeff that I'm going to be looking into. Thank you. And I'll know more once I go through that. If I can't make some serious headway in this area by this afternoon, I think I'm going to put this down and focus on the Groovy Braille Lake. Just for a second. Seems like a reasonable point. Yeah, I mean this one's a time sink. And what it sounds like it's going to end up with is there being a bug to the Java compiler or somebody else, not in Jenkins. Well, maybe that there's a workaround we can do. No, OK, fair enough. It's not the first time we've done workarounds for Maven, especially Maven compiler plug-in issues. There's an existing one for annotation processing that we have. Fair enough. So we hit this issue as well for some demos. So it would be really interesting. Yeah. OK, thank you, Sam. Ben? Yeah, so basically what I've been looking into is in the worst case scenario that we just can't figure out the Java 10 compilation stuff any time soon, it's relatively trivial to compile using Java 8 but run like unit test using Java 10 and up, which for validation purposes gets us most of the way to what we really need to be able to say, like, yes, we're OK with things running on Java 10 and 11. So for today, basically my goal is to kind of finalize a demo for tomorrow and maybe add some or propose some new images or whatever is needed on like ci.jankins.io and maybe even update the build plug-in groovy library to basically allow someone to test building using JDK8 but running on Java 10. Just like the Java 10 images that we have there right now. Do we want to turn that on for Core at the end of this? Or are things too? I have no idea about whether it worked for Jenkins Core itself. I mean, theoretically it would, but I haven't tried it. Basically the way I'm thinking of it is in the build plug-in groovy script that plug-ins are able to use, they can select JDK8, JDK10, I guess now. They can select versions of Jenkins to test again. So my proposal would be to add another thing that if they want to, they can test also against JDK10. But maybe, yeah, there's certainly we could discuss making that like a default thing or something like that. Yeah, just a second. I stop my screen and respond OK. I'm sharing my screen again. OK, yeah, regarding pipeline library patches, yeah, I'm the next, so I'll just do the update. I did some patches in order to enable that. I have demo Jenkins configs code presentation, which I have already demoed on Tuesday, quickly. So I updated it to support JDK and 10 and 11 builds in a tricky way, but maybe it's something which could help because it supports running a doof plugin and a lot of other pipeline library tools. Yeah, regarding the rest, we finally got the BCT released and I've created upstream pull requests to Java 10 and master branches, so Java 10 branch is integrated and the images are already updated. And yeah, I also did some testing of Oliver's patches for animal sneaker. They look good and yeah, I've added some tooling in order to support that, but we are still waiting for the release from Oliver in order to update, for example, SAMS pipeline support plugin build flow. Okay, and the rest I spent maybe three hours today running Java 10 on Windows, use work files. And unfortunately I have to admit that so far it just boring because it works. Darn, what a bummer. Yeah, so it's a good result, but yeah, I expected something to break. I'm not successful so far. I have some ideas and I plan to continue tomorrow. Well, I guess we're just gonna have to cry ourselves to sleep then, aren't we? Yeah, on that one. Yeah, let's see. Okay, that's it from me. Maybe we will also do one release for the app streaming. I wanted to discuss today. Okay, Nikola, is he online? He's not here. Okay, Jean-Paul is also, he's at the conference, but he is going to do a demo of Easy Jenkins tomorrow. And yeah, it will be a part of our status update presentation. Okay, then Kiki, are you online? He's not here, nope, and... Okay. Yeah, I don't have anything to add today. Could you please ping him in the chat just in case he missed the update? Okay, we'll make sure that he's here tomorrow. I think that's a reason for this. Yeah, but actually Kiki's update is here. So he's working on removing Jax B from the core. He tried one update with detached plugin. It didn't work due to some class loading issues. So now he's exploring plan B by just bundling libraries of Java 8 compatible versions directly to the Word file. So this is the update from him. Okay, Lime? Yeah, I don't have anything to add. And now update. Denius, he has created some tickets and he started working for Docker packaging for Slim and Alpine versions. But we discovered that there is no Java images for that. So with this, there are still things to consider. Whether we need that and if yes, how to proceed. Tracen? Hi, yeah. So I did some more exploratory testing that was running on Docker with the image. And yeah, nothing exciting at one issue where the email extension plugin didn't show up submitted a bug. But I think we talked about that, that it's likely a packaging issue with Blue Ocean. And yes, almost more issues in the documentation than in the product itself. And then in general, start a full request just to have some information on Java support. So when folks run with different versions of Java, they'll have a page to look into to see what the deal is. Oh, and I'll add, yeah, I was working yesterday with Jonah Graham and he managed to get in a couple of pull requests. And yeah, general feedback was that it was really easy to get up and running, both with Jenkins Core and the plugins, less straightforward to sort of trying and come fix sort of illegal reflective warnings just because there's a lack of sort of understanding of the architecture decisions. But yeah, he did manage to get a couple of things in. I think I've put links to the PRs. He did a bit further down. Yeah, one of the cards was about parameterized, not trigger, something else plugin. Okay, we can find them later, but yeah, one. I think just in the doc, I've put them in the doc a bit lower down if you just go down a bit. Oh, my bad. That's okay, you can just paste them in there. Okay. So yeah, this one already got released by Baptiste Matos. Yeah, that's great. This one, yeah, there was a discussion between Nicola because there was one proposal from Johan and then Nicola made another proposal based on his approach to rebuild packages. So, yeah, this is one version of the pull request and there is another from Nicola. So, it's based on the blog post he published yesterday. By the way, I need to find a little bit. Okay, yeah, so I'll just update for Nicola. Yeah. I think what was interesting as well for me with that patch, just understanding what Nicola did with the multi jar and also that this is the first time I'm seeing something where Java 10 is actually fixing like using that new AI fixer something and makes it work on Windows where it didn't before. Mm-hmm, nice. Yeah, that's cool. Yeah, Nicola also did the patches for core and he's working on the touching GNR library. It's one of our sources for illegally reflective object services and previously in December, at this they even did a lot of work to clean up core. Now the idea is to remove this library tool and make it a detached plugin. It would be great to detach JNA at the same time, but I think there's still a lot of uses of that in core. Mm-hmm, yeah. So, yeah. Okay, I think that is just a subject for discussion, but yeah, Nicola will be proposed a couple of requests with some changes. Okay. What else do we have on the call? This is Jeff. So I haven't had a lot of time, but I managed to dig into some compilation stuff a little bit. May or may not be related to some of the stuff Sam's seeing. Hard to say, it's very initial so far, but I found the annotation index or is not making a fix in there, recompiling it, rebuilding it under Java 10 or 11 seems to allow the build to proceed further. I'd be really interested to see the manifest differences between the JDK8 build and the JDK10 build. Yeah, there's a lot of things I'd be interested to see on this one, it's very initial so far that I found that I was able to get further with that, and I have no idea what's going on yet. I've had very limited time, as I have more time, I will continue digging into that, trying to understand what's going on. Mm-hmm. Thank you. One trick I wanted is to do parallel builds, do one build with Java 8, JDK8, one with Java 10, and then literally just use method. I tried to create such parallel builds, but for me, the build just fails at all now. So Jeff, if you submit the patch for that, I will be happy to evaluate and integrate it. Do you want PR out, actually? Yeah. Can you cut me, can you cut up PR from that stuff, running chance? Was that to me, I missed that. Yeah, I was wondering if you might be able to, actually, you know what, don't worry about it. I can create a PR from what you've described, that's not it. Okay. Yeah, I can create one, I'm just not entirely sure when I'm going to be able to get to it. If you want to do it first, that's okay. Give me a second. I'll have you one. Bip, bip, bip, bip, bip, bip, bip, bip, bip, bip, bip. Were you building explicitly for compiling for Java 10 in this case, or are you still building for Java 8, just changing that field? I've been building with 9, 10, and 11 and trying what goes on. And the particular line that I indicated that I changed or added in that particular case. There's an addition for Java 9, which makes it work okay in Java 9. But then with 10, the string changed and 11 seems to be the same as 10. And I've just been building mostly with 11, but trying 10, nine, see what goes on. Okay. So I guess we need to do some comp in the chat later. Yeah. Okay. So that's it, these updates, I guess. Okay. So what else do we have in our agenda? So the first was about Java 10 support page. So Tracy starts drafting this page in the bottom of the document. Tracy, the floor is yours. And if you want, you can just take a screen share on your own. Yeah. If you could just keep sharing the document. Okay. I guess that will, yeah. For this. Yeah. So this is just a proposal for, I don't know if we can pin you, for the wording we should have. So at the end of this week, we give some clear direction to the community, what versions of Java they can use. So we just say that Java platform will run, sorry Jenkins will run with Java 8 runtime environment, but say that Java 10 will be preview. So it may be run with Java 10 by specifying the enable future Java flag. And then we put a link to known issues. And similarly for Java 11 and beyond, we say, well, you can do this. There's lots of caveats. So I don't know, there's a proposed wording. So it likes some feedback from people whether that's strong enough, encouraging enough, have yet it in more ways. Yes. I had some comments. Generally, I totally support having this page because currently the only thing we have on Jenkins, I always something like installing Jenkins guide. Yeah. That goes here. Yeah. And it says that Java 8 is a prerequisite. So yeah, this is the only thing we have now on Jenkins.io and having a kind of official page which lists support options and maybe experimental support, it would be really helpful. Because nobody really reads this page, I guess. We've got so many issues about Java 10. So what Tracy already did, she created a pull request to extra executable board. And yeah, this pull request, it's some redirects. And yeah, when we get the page done, we can just redirect users to Jenkins.io so that they see actual documentation and we can update it dynamically. So it should help a lot. That's very cool. Any other opinions? Do we want to have more details than this on the page? I mean, like you have a bunch of different things in the blog post, are all of those basically? Yeah, so my opinion that this guide is just not going to work because it's just too top level. So Kiki is currently working on a fix in order to make Jenkins running with just this option. By packaging the Jax B, but so far, it's not there. And yeah, I would say the other reference since not this guideline, but maybe a part of this guideline. So for example, we could take these run guidelines. Yeah, someone does instructions and put them in the middle of the page, yeah. Yeah, and I also think it would be important to reference this ready to flight packages because this package, for example, is really important for us because it includes some patches for pipeline support. And yet I would rather expect to see a page which includes this experimental guidelines and also experimental docker packages. And then we know that that's the thing that we update and everything points there. Right. So the rest of this section is not required because Tracy is detailing two JIRA tickets describing there. Right. And yeah, actually maybe we could add some notes, for example, for pipeline, what needs to be updated. So similar to what has been created for our status updates document somewhere. Right, yeah. So I was wondering if we should have maybe an updated version of that blog post. And then link it from the page. And the reason to just have it in a blog post is because it dates it. So I think this will get, it will change and get stale quickly. But if it's in a blog post, at least it's saying as of this date, this was the date of it. And then we can kind of swap out the link as we update. So I would suggest that if we have it in the docs then we can say or have a note somewhere on the bugs that are added under the Epic to say, when you fix this, you need to update the docs. I understand that the desire to have it updated, but I still want that doc to exist. I guess that we shouldn't be using blogs as the target of things, I guess. Yeah, but likewise, we shouldn't be having lots of caveats for running with Java 10 and 11. So I guess this is a kind of work in progress, I suppose. Yeah, so what we could do, we could create a Java support page where we describe explicitly what we support. I mean, so something like this, we support Java 8. Yeah, I propose to be a bit specific, but yeah, this is what we support. We also explicitly say that these versions are not supported. Then we can add information of what actually mean supported agents, master, whether you can build with other Java versions if you want, because these questions are very popular. If you want, I can just add it here. Yeah. So for example, to do as a user, can I build my project? So Tracy, I agree with the idea that we want to, I agree with the idea of like, okay, targeting is okay, as of this date, et cetera. To me, I guess having a blog post be the source of truth feels kind of hacky. It feels like, oh, you guys didn't write the documentation. Oh, you just have this blog post, it just looks odd. It's an appearance thing more than the actuality, but I don't care where the page is exactly. But it's like, oh, so you did this blog post. It also makes it very apparent if it'll make it, well, okay. So when we do an update, do we post another blog post or do we update that blog post? With a doc, you very obviously update the doc. With a blog post, we generally don't want to be going back and updating blog posts over time. I agree with Liam's points there, actually. But if I could offer maybe a compromise, could we do like an efficient doc, like finalize things, like this works, this works as of these versions and then a blog post for kind of the interim workarounds that basically shows like a snapshot in time. Here's the workarounds that we know about versus here's the things that are considered done and fixed and stoned in the docs. And then we add to that as things get kind of finished off. I guess I'm not understanding what you're pointing to. So we still have a wrap up blog post that says, here's the state of the thing. So, which I totally support doing, by the way. I totally support having a blog, a wrap up blog that says, here's the current state, right? So your points about there being issues with updating a blog, I agree about. I think a blog post should not be the central source of truth for support. And we've historically had problems with that. But it is useful as a snapshot in time for workarounds. I'd like to have things that are kind of permanent documentation captured in documentation. So, here's what's supported, here's what's, I guess things that will be updated and added to, basically. And reserve the blog post for temporary workarounds. And here's our current status, basically. But that makes no sense. I'm not sure how that would work, so we would just say that we would have a document page that points back to the blog post to say, here's the set of workarounds, because otherwise you can't run, right? Yeah, we could actually, yeah, we could, I know that sounds crazy, but we could actually do that as a starting point. We could have the documentation, plug in some basic stuff and some basic information that we know like pipeline works, these things work, and that points to eventually, that'll be in full documentation, but while there are still workarounds required, that would point to an updated link to whatever blog post we wanted to have for the workarounds. And eventually, anything that needed to be a permanent part of documentation would eventually migrate into the docs. Yeah, we'd rather agree with this approach. So, Java tends to- Okay, so then, so when we remove one of the workarounds, do we update the blog post or do we- The doc. So the workarounds do go in the doc. Once it becomes permanently functional, it's part of docs. While it's in a transitory state, I think it's okay to reference a blog post for short-term workarounds, but short-term workarounds have no place in long-term documentation, unless there's something that's gonna be permanently required. Does that make a little more sense? Like docs, docs, I feel like the doc should be stuff that reflects accurate state, basically. The doc should always be up to date with where we are. But it's a key reference, something else, so we aren't duplicating ourselves and having to have the same content in two places. Okay, I think I see what you're saying. I mean, it may be crazy. Maybe I'm hard to get too fancy here. Tracy, what do- Yeah, well, I guess my big question is, how close are we to having a simple solution for running Java 10? So, with it just being one line of saying, yes, you can run Java 10, and it's preview, so that we won't be- Here's the one line of command that you do, so that you don't have to say a lot of things, right? So, does it come down to the Jax B thing, or more? Yeah, so far it's Jax B, I think. Some of the plugins still have dependencies on versions. If I recall correctly, the WorkFlows support plugin that dependency we have there may not work with Java 8. So, we do have to have some sort of multi-release to our support baked into a couple of things. A WorkFlows support plugin works for Java 8. Does it? Yes. With your watch? Okay, and I don't remember exactly where it was. It might not have been that one, but one of the patches that we made is not readable for Java 8, I remember that much. It'll compile and it'll run in Java 10, but it's using Java 9 source, or Java 9 class files. It was a multi-release jar, at least when it starts compiling properly. Yeah. I don't know if we got far from having support, but we definitely do need to have some, there's some parts that we'll need to release because they just can't work under both. Have to have different code or different dependencies. Yeah. Anyway, I feel that we are retelling a bit. Yeah. So, I think all of us agree that having Java 10 support page would be useful. So, if we're just like, is it a Java support page, right? Yeah, just Java support page. Yeah. So, it's a landing page where we have statuses, where we say that Java 8 is supported, we say that we have Java 10, Java 11 in Preview mode. For example, with a link to the blog post, or maybe there's some basic description on this blog post, and then we have Java 7 and earlier. And we'll try to put, what we put in there for Tracy's point, we'll try to put it onto that page and stuff that isn't just transitory. It'll be something that, okay, this is going to be this way for a while. And so we're not, it's a try and put the stuff that's less likely to just go out of date, right? Right. Yeah, I agree. I'll have a second pass at that so we can have a look again tomorrow. But yeah, I hope we can just get Java 10 in a way that is kind of one line to run. That would be, yeah. Yeah, so what Kiki is working on. So once we get there, yes, of course we can remove these things, but it doesn't replace a lot of guidelines. For example, we need pipeline support plugin to be released at least, which is not exactly going to happen soon. Maybe soon, but we need to figure out how to release it at least. And I think saying what we test against is also very useful. Yeah, right. Something that I think would be legitimate to slip into the work stream for the pipeline team. It may not happen right away just because there's some testing needs there. And I'm a little twitchy about growing out major dependency bumps like that really nearly. Okay, not that I've in that horribly break something in production for users or anything like that. Okay. So if you agree on that, yeah, maybe we already discussed it a bit tomorrow with more detail or at least with some specifics. But yeah, I think we are in agreement how it would look like from the top level. Yeah, sounds good. Cool. Okay, let's move on then. So next topic is upstreaming core changes. So we had a bunch of changes created against our Java 10 support branch. And yeah, there is an interest to start upstreaming them to weekly releases in order to firstly minimize the size of Java 10 support branch. And then when we are ready to just say that master and hence weekly releases support to Java 10, then we can just drop it in. Actually, we don't have so many patches inside. So we have one patch regarding the general post-exit update from there. That doesn't necessarily matter if we're just going to get rid of it. Yeah, so you think it doesn't matter? Yeah, because I mean, we're just going to, all it does is potentially clean up some illegal access reflection, legal reflection. But if we're going to move it out of core anyway, it seems that important as long as the detached plugin is the nearest version. Right, anyway, we can just propose this patch if it's harmless against master. Then we have a patch from Sam about GroovyBump. As Sam said, it causes memory leaks. So we cannot upstream it in the current stage. And it's needed to run declarative pipeline updates. Yes, and I think once we have what I would suggest we do, at least for this, it is, one of my goals for this week is to have at least a proposed patch to fix those memory leaks out by the end of the hackfest or at the latest on Monday. Once that has passed review and is in release, I think that'll cease to be a blocker for upstreaming. I want it to be unstuck there. So, do you not, then, Groovy call this memory leaks? Yeah, and that's actually subtle because that'll cause memory leaks in places besides pipeline. As always. Well, there's a fix. When I say I'm doing a patch for preventing the memory leak, that's actually two patches. That's one to work for the CPS for pipeline and one to script security to cover other random Groovy usages. Like dynamic parameters, those extensible choice parameter. Oh, you'll have test to mention follow that, right? Yeah, that's the main reason I'm really pushing hard to get compilation and testing working under Java 10 because then I can use the existing test cases to validate my patches. Okay, that's really cool because when I've heard about extended parameter, it was really surprising, but it's great to hear that. Okay, so yeah, this one would be rather blocker for us. And I think that one needs to, I would say that one is a good one to have marinating in our weeklies for a little bit because every time we bump Groovy, there's always a little bit of risk associated with that. Yeah, right. But yeah, once we get known issues fixed, yeah, we can proceed with weekly update. Yeah, and the weekly will probably not do any other issues, I think. Yeah. Then what else do we have? So it's, yeah, we have bytecode transformer. So we also have some minor tooling patches, but yeah, in the code generally we had some upgrades. And yeah, he is a major bump, but I spent some time today testing BCT. So I've already created a pull request against master branch. It has been approved and it works like a charm. So no problems discovered so far. And yeah, if everything goes well, I would like to really integrate it. So it's ready to go. Once we have these three fixes in the core, we will get to the state we have now with our development branch. And I think it would be good enough to say that we have some demo support of Java 10 in the core. However, there are ongoing pull requests. For example, pull request from Nikolay about the GenR-Porschex pull request from Kiki about Jax B. But these pull requests can land directly in master if needed. So they do need to pass through evaluation how we can do that. Okay. So if everybody agrees, I will just create follow up tickets. I have already an epic for upstreaming Java 10 changes. Just a second, I will find it. Okay, yes. So I've already created epic Java 10 support mesh to upstream. I will create tasks there. And if I'm missing something, just add them to the ticket. Okay. That's it from me. Do we have any questions on this topic? Am I still online? That's... Okay. Thank you. And last but not least, testing of plugins with Java 10. So, yeah, there in the floor is yours. Yeah. So we already mentioned this kind earlier, but the big idea here is to basically allow almost unchanged build and test flows. So that if these compilation errors take some time to fix, we can still move forward with testing the Java 10 changes and are like our standard flows. And so my goal here is to basically get some examples, demos of running plugins with tests on Java 10 and with the PCT with the test run on Java 10. Basically, it's very trivial. You just have to pass the flags to the Maven Surefire plugin to tell it what JVM to use specifically for running tests. So it means that we'll need agent images with Java 8 and another version of Java installed. But other than that, it's like, you know, very minimal changes. So it should be pretty feasible. And so does it run with stock water files or do you package them somehow? So for the PCT, I created a custom war file based on our Java 10 branch to get like the ASM updates and stuff like that. But once those things are merged in, you could use your standard war files. You need to make sure that you have all of the plugin updates, like experimental releases of workflow support or whatever for those tests to pass. But I mean, you can also run plugin tests directly from the plugins repository, not as part of the PCT. And so that doesn't require any kind of custom wars or anything. Just directly you change the configuration. And so I guess the other nice thing about this year is that it doesn't actually require you to go in and make changes in plugins. You would just be changing the CI jobs. Mm-hmm, okay. It looks like a nice workaround. Yeah, and certainly this, I would imagine this would be totally transient. Once we get to a point where we can build on Java 10 we would absolutely replace it because it would be simpler. Mm-hmm, that's nice. So we already did some experiments with this flow. So you probably know there is Jenkins Essentials project going now. And yeah, there are steps in pipeline library for PCT. So for example, run PCT groovy. It's a step which allows running PCT with passing custom Java options that I mentioned. So in CI Jenkins IO and in Jenkins files for plugins it would be probable to use this flow out of the box. And we also have some data driven development automation. It's called Essentials Test here. So it's just a build flow which firstly builds the plugin. Then it uses some tool called Custom Work Packager in order to bundle all dependencies needed. And it runs ATH and PCT. So we experimented with this approach for integration testing. And I guess that Java 10 integration could be one of the use cases. Definitely. So everything work in progress. But you said the update that you've already done and got to test running, right? Yeah, so this all works locally at this point. It's trying to get some actual Jenkins files. Updates, maybe update pipeline library on CI Jenkins IO. For now I'm using Oleg's standard demo image that he uses to test it out locally on a Jenkins instance though. Yeah, this is the demo I was presenting with Java 10 support experiments. So it great that it works. And in such case we will be able to do some testing once we are ready to upstream these versions. So we will be able to at least have basic CI for plugins which we recommend in Installer Wizard, for example. Okay, thank you. So any questions regarding this flow? Sounds good. Okay. I guess they sit for today now. Does anybody want to discuss any other topics? I'd like to get a confirmation from Jeff that he didn't do any other particularly custom palm changes for his tricks. Yeah, all I ended up doing on that was the one line change and the annotation index or whatever that was called exactly. And then just update snapshot build, build everything locally down the chain and around. I didn't solve everything, but it did make me allow me to get along further in the build. I'd be curious too if you just built it and skipped the test and didn't even make a change if it would do the same effect. I mean, that's an obvious question, right? And I haven't tried it. Well, I'm trying it out. So this is, yeah, this pull request ideas. Nope. That's an older one, isn't it? Yeah, but this is the only one. Right, yeah. So you haven't submitted your pull request yet? I haven't. I haven't had a chance to. Sam, you were going to? Yeah, I'm testing it out to see if it actually does. Right. Mm-hmm. Okay, thank you. It would be great. Okay. If there is no other questions, we have another meeting tomorrow. It will be a kind of a close down. So we will have some status updates and presentations. So for example, we will have a presentation about simple Jenkins and update to Java 10 there. And then they even also wanted to show the flow if it's done by this time. So yeah, maybe we'll have some such demos. If you want to present something just to close down the hackathon activities, let me know in the chat and we will organize the agenda. And if you want to join this closed down session, we have Jenkins 10 online hackathon on meetup.com. And here you may find all the links. And here's the link for the meeting tomorrow. Okay. Excellent. Nothing else from me? All right. Oh, hold on a second. So in the change and annotation indexer, I did update it to a more current version of the main parent Jenkins palm. That was one other change that I had made. What version did you bump to? Because I just found, it was actually just about the thing that I tested it and it still has the issue of being restricted. Yeah, it looks like I bumped to 46. I'd forgotten I'd done that one. Thank you. Okay. All right, this. And I was quickly here checking through my others to see if there was anything else I found. And I haven't checked them all exactly, but it doesn't look like I changed anything else. I can go review that more carefully, but. Okay. So. No, no, still get money or okay. I, if you mind if I stick on with, with Jeff, we can take it offline and all. Yeah. Sounds good. Yeah. Let's take it offline. It's better to discuss it in the chat. Yeah. Okay. So then that's it. Thanks everybody for watching and see you tomorrow. Cheers. Cheers.