 Okay, welcome everyone. This is the Jenkins platform special interest group. It is July the 30th, 2020. Thanks for being here. Today's session we're going to talk about open action items. We'll review adopt open JDK for Docker on Alpine, Debian Buster and Santos. Alex will talk about deprecation of Docker agents images using the Debian operating system stretch. And then Rishabh has a question about extension development that we'll address. So please to note that the meeting URL has switched to the CDF zoom account and I've done all the actions for it. I have not completed the JEP for Docker operating system support and platform selection rules yet. Yes, I'll get to it. The Docker build work rework PR that I believe is actually distinct from the Alpine transition right for the adopt open JDK transition. Yes, it was rather for platform support. Great. The adopt open JDK is also on the table. Right. Okay, so this one, this one still is open. We've still got work to do on it. It's got looks like some request for changes from from Alex. And yeah, good. Okay. I need to look back on again, because I think he has done all the changes I asked for. So I will update my review. Great. All right. Let's get that one in before the adopt open JDK switch just to because Jim has a lot of work in and it's looking good for my side. So we'd like to get that in if we can. And now the build rework that Jim did that is just reworking current images that doesn't provide us with with S390X image or power PC image. That's great because we need to switch to adopt open JDK. Got it. Okay, great. Thanks. Excellent. Thanks. And then review the alpine image update PR and I think this one may be. This is the use adopt open JDK one. Yes. Okay, great. All right, so this is the one that's mentioned in that next item on the agenda here. And again, the action there is more review. The sequence more review of this one review and final sign off of 922. Right. And then I would have to possibly do a little bit of rework on my PR switch that adopt. Right. There may have been so much files changed and stuff like that. So, right. It was mentioning I am a great agent. It's a lot of images to adopt open JDK. So the recent beta 15 release runs on the adopt open JDK. There were a few differences in packaging, for example, get et cetera. But in general, it works pretty well. I think in most of our images, we may install it anyway, or you have to do so. I think we're okay there, but that's good. Yeah. Also, there is an interesting chemical adopt upon JDK 11. Which is actually just 15 megabytes. Yeah. Oh, yeah, I tested with Jinx fellow runner that works quite well. Well, I'm trying to come press my own part because Jinx fellow runner is about 200 megabytes right now because of the fact that it's prototype. But yeah, my overall experience with adopt open JDK is perfectly fine. All the tests et cetera pass without any issues. And it's not a surprise because staging also runs on adopt open JDK. We haven't noticed any problems. That's very good news. Excellent. Anything else on adopt open JDK for Docker on Alpine, Debian and Centos. Next topic deprecate the Docker agent. My fat fingers deprecate the Docker agent stretch images. Alex. Yeah, so as we go to switch to adopt open JDK, they do not have a stretch image. So this is right now this is for agent Docker images. Most of the Linux images are still using just open JDK base image. And so if we move to adopt open JDK, we would not be able to make stretch version with adopt open JDK. So I propose deprecating those. So Debian stretch would not be included. So basically to drop Debian stretch when we switch to when we switch to adopt open JDK. And I would say deprecate because even if we still if we keep building with open JDK, then we've seen that those images are not updated. And so there are possible security issues. Going forward in the future. So that's my reasoning behind deprecating. Is because they would not be able to be updated going forward. So we would continue delivering Debian stretch images. But using using the open JDK rather than adopt open JDK. Well, what there is, what's there now. But like I said, the problem is that there are no updates to that image. So if there are security issues that come up. And that's a problem we can't update it. So that's why I propose deprecating. Got it. Okay. So open JDK when they released 262 for instance, 8u 262. They did not update the Debian stretch image. That's my reasoning. Okay. All right. So that that explains why I think mine is still running 232. Because it's based on the Jenkins core. Okay, thanks. Any discussion needed around the question that it seems like it's a clear, clear thing that we should do. So we're just acknowledging that we want updated images and Buster has been out for a long time. The next, the next release after Debian stretch has been out for a very long time. So we just have to determine whether we want to publish images or just leave them as is with the display version. That would be the question. So, yeah, what we could do, we could actually do a final release of these images. And the injected deprecation warning right inside the entry point. So anyone who launches this image gets an error message in the error that the image is deprecated. And after that, yeah, we can link them somewhere. And after that, we can stop shipping the images. Okay, so like, I wanted to be sure I captured what you said it was final release of the images with a deprecation warning in the entry point. And then then it was a lot of stop publishing them. So for the users later or whatever with this tech, they will get a warning. But for CSC again, we can have one version of the warning. Okay, so we'd stop publishing images after the deprecation release. So would the deprecated version remain published for an extended period so that those who aren't immediately upgrading or I see no practical need to remove it. Okay, all right. Yeah, I understand that we might want to remove it just to highlight the problem if somebody uses them. But at the same time, to make close and predictable impact on automation flows. So it's rather just stop publishing them similarly to like we did before with renaissance with terminology updates. Yeah, for terminology, we still keep publishing cold images, but in principle, I wouldn't do that. Great. So any dissent from that proposal, that sounds wonderful to me. Alex, particularly for you, is that okay with you? Okay. And a deprecation warning. Yeah. Yeah, one question to you, Alex. What do we do with a given buster because defaulted opto images are actually based on Ubuntu. Not on Buster. They have a buffer image. Okay, so yeah, we'll keep a buster as a default, right? Yeah. It's rather Jenkins default image. Oh, yes, Jenkins default image. Open JDK buster. So they do have a buster image for adopt open JDK. Yes. Okay. Great. Anything else on deprecation of stretch? All right. So next was a question from Richard Richard extension development question. So I've been trying to develop a new extension, implement a new extension from an extension point within the plugin. And the extension I'm developing is in the GitHub brand source plugin. So my question is that while I am implementing the extension point in the GitHub brand source plugin, I need a class from the get plugin, which is not, it doesn't exist in the existing release of the plugin. And to do it locally, I have a simple hack of, actually it's not a good hack, but I just replace the job in the game to depository. But what is the right way to, what is the right approach to do it? How would I, since it's a get plugin is not an external dependency within the form of GitHub brand source. I assume it's been taken from the parent form or something like that. I'm not sure how is it being added to the GitHub brand source plugin. So how, how, what is the right approach? I think, I think you would want to add that dependency, add the dependency to the branch source plugin that you're developing against. So on the get plugin, add the get plugin dependency as a, as an entry in its palm. And then the crucial thing is use an incrementals version number as the, as the version on which you depend. Okay. So, so if we look at, I'm going to bring up, let's bring up here, we'll just do it in this other window, bring up Jenkins here and let's look at the get plugin. Oops. It's, it's the get plugin you need not to get client plugin. Right. Yes. Okay. So if we look at the extension point is declared in the perfect. All right. So if we look at the, at the builds on the master branch as one example, and you can also do this with, with should be able to do this with pull requests as well. But let's take a look here. This should have, I don't know, wait a second. Is this failing to publish incrementals? Okay. So the shop I may add, let's see if we can do it here. Or one from here and. Okay. So it looks like I have a fix to make. I apologize for this. I'm going to have to show you with get client plugin. That's a good cause for embarrassment. Sorry for the embarrassment of the, the demonstration I wanted to show is a complete failure because it's not available. There's a, Jesse Glick was very kind. He pointed out, look, Mark, you're being a little too, too tricky in the build plugin call that you're making and you're broken incremental publishing. So we fixed that in the get client plugin where you should be able to see. Here we go. Now this, so I'm going to make this much bigger so that it's actually readable. Oops. Okay. So when you look at the, at the successful artifacts built from the get plugin, you'll see this get client plugin. You'll see this magic here in the, we actually publish the jar and the HPI every time. And this is an incremental that you can then reference in your palm. So, so it should be enough to reference that thing, but we've got to fix it in the get plugin so you can do that. So either that or we have to release. And I'd rather not release with a preliminary version just so that you can do development. So this notion of an incremental. Let's see if I can find. On Jenkins.io. Because there is a, there are, there are good, good instructions or good insights from here we go. From Jesse Glick on how to do parallel component development. So this one is specific to, to the Jenkins core, but it's the same thing where you grab the version ID. And then update your plugin palm to use the version ID. Based on that. Okay. Now, now again, my apologies. This means either your first action is to fix build plug, fix the Jenkins file on the get plugin, it's probably better if you do it, model it after the one that's in the get client plugin. It will be sad. It's sad for me because I like all the sophistication I put into that Jenkins file. It does random version numbers. It does all sorts of elegant little things, but it breaks. An important feature. Okay. I look into how it's been implemented in the get client plugin and I'll try to. Yeah. For what it was, you can always deploy timestamp snapshots, which is the easiest way to get something running and demonstrated. Oh, oh, that's right. Okay. So I like to be more precise or to be, to be more detailed there. He could just do a make or a maven clean install. From the get plugin directory. And then he could reference that. Is that correct? Or tell me. Deploy. Maybe. Okay. So. Alternately. Even clean deploy. Locally. And that will then then depend, then you would depend on the snapshot. Right. No. Well, it's a snapshot, but it's a timestamp snapshot. So what it means that it gets deployed to the Jenkins factory. And it will remain there for a particular amount of time. If I recall correctly, two weeks. And during these two weeks, it can be referenced. From my new pull request in other component. So that you can test it. So my fear is that he probably does not have permission to deploy to the, to the get plugins. Section of the. To have permissions. Oh, okay. You can deploy a snapshot. See if you're locked. So you still need to configure your environment in order to push. Releases. But you don't have to have release permissions to deploy a snapshot. Okay. Even, or like, even if I don't deploy it and I build it locally in my machine. Will the gate of branch was plugin. Wouldn't it be able to find the, uh, Jar snapshot jar from my M to depository for my local development development. Yeah. So for local development, you can just run clean install. So clean install is not good. It's not good. It's not good. It's not good. It's not good. It's not good. It's not good. It's not good. It's not good. It's not good. It's not good. It's not good. It's not good. It's not good. So clean install is not good for. Testing because. Clean install is just limited to your machine. So if you want to. Demonstrate, you need something better. And. Okay. So collect the password from the. all that password you just need to follow guidelines so it doesn't it doesn't require any credentials at all no it requires your Jenkins credentials but they Jenkins credentials you don't have to okay so it's in place your Jenkins password in the art in the Maven settings yeah okay all right and then Maven deploy and you say will last it will survive for two it will last for two weeks I don't recall the exact time but yeah it remains active for long enough time so that you can get your PR will refight and even if it disappears you can lose a deploy a new incremental version and yeah I use timestamp snapshots for development because in such approach I don't have to wait for incrementals to be built okay but yeah it's a kind of not so official way being compared to incrementals because yeah the most of contributors moved on to incrementals but yeah that's great thank you so Rishabh any questions no I understand what I have to do now thank you so much Oleg and Mark I'll I'll use this technique to depend on the get up the unreleased classes I need to depend on excellent yeah thank you oh like thank you very much I wasn't aware of the alternate technique I'd never never I'd always just done that Maven clean install and accepted that's that's really great okay any other topics for our meeting today not for me so maybe related topic switching sergeant to say how to use github application authentication and for example packaging repositories have been already switched so it means that docker images and also native packages when you run CI they authenticate as a github application and the next step is to actually have warnings in G plugin it's already installed on the engine and say no and the one of JSOC students casual he is working on the integration of these github checks API this integration has been reduced but it hasn't been yet deployed on the engine can say no but once it's there we can for example publish docker scan reports etc because there are standard formats which we support by working in G if I recall correctly and definitely we can start doing things like just static analysis so whatever for the images and yeah no you had mentioned that plugins need some additional additional discussion or additional approvals could you describe more just models from users so literally it's one setting to be changed and for example I already changed Jenkins core to use github application so yeah for plugins it just impacts a much bigger number of people so why it didn't implement it result additional feedback if you're interested it's in the infrastructure mailing list yes absolutely so my whole hearted approval that's that's really positive and again another thing so if somebody is interested in advanced plugin management that is fished full request from Tim Jackham which includes plugin installation managers tool in the official broker images now that one it seemed like there were some some issues that Tim was still working through that plugin installation manager needs some further changes before that's ready to go production yes it has issues but in principle for common scenarios example when you define now all plugins on the top level it works quite well so it's once it say released it will be available for evaluation hopefully it will help to facilitate more feedback so what we discussed that basically installation manager will be shipped as preview so that anyone who's interested can try it out great okay so when when we say ship this preview does that mean that it will be in the Jenkins slash Jenkins image or do I need to use the experimental image Jenkins Jenkins okay so it's just it won't be enabled by default so what it means that install plugins as a script remains basically the same so unless you would switch to the new fall you will be using those in the other items we should note in the in the in the in the meeting all right let's call it in thank you we've got Google summer of code meetings presentations coming in if I remember right about an hour right oh like where we start 30 minutes 30 minutes from now looking forward to the 90 okay so looking forward to Google Google summer of code demonstrations later today it'll be great thanks thanks see you