 and then off we go. So welcome to the platform SIG meeting the 13th of August. We've got a topic on the agenda related to adopt open action items we'll review briefly. Adopt open JDK for Docker on Alpine or for let's talk Docker on Alpine only. Alpine adopt open JDK 8 for Docker on Alpine and then we'll create a separate item for adopt open JDK 8 for Docker on other platforms. There we go. So there's been a so we'll discuss that separately and deprecate the Docker agent stretch images GitHub app authentication on ci.jankins.io. Let's am I sharing my screen? It would help if I shared my screen instead of just talking to it. Sorry about that. There we go. Okay. And the plugin installation manager in Docker images. Probably Tim. Yeah. And I think that one is just a status report. So that can be me or you Alex. Right. Because it's it's available. It's intended to be available preview mode. And we'll we'll talk to it. Anything else that needs to be on the agenda Alex? Okay. Great. All right. So open action items awkward and embarrassing one. A jet for Docker operating system support has been made intensely more needed by recent disclosures recent public disclosures. Then we've got the Docker build rework PR that's going to be delayed and then an Alpine image update PR that one I've been evaluating. But I think we need to shift our focus for today on to adopt open JDK eight for Docker on Alpine. So this one the story is that a there's been a public disclosure of security vulnerability. So work is being done now to address that. And there's really no fix based on open JDK because open JDK has dropped Alpine support. So we must use adopt open JDK eight if we want want to fix. And that's what Oleg has submitted as a proposal. Alex any concern there from you in terms of accepting a breaking change in order to make that transition? And so the there are pull requests pending to update Docker the Docker image, the agent images, and it's multiple agent images if I recall correctly as well. Yeah, we need to shift all the repositories. So in this case, Docker SSH built agencies the biggest priority, taking the nature of disclose issues, but other images also require date. So in bound also base agent also all general P agents think because they also include dependencies on Alpine versions. Yeah. So I will focus on Jenkins controller release and on agents first. And I would appreciate some reviews for SSH agents. I pasted the link to the chat Alex because the pull request build the fails on Windows due to strange issue. And yeah, since it's on Windows I make both assumptions that we don't want to get both by that but at the same time I would appreciate review if there is a fix we could apply. Yeah, I think the issue is this one was never updated to pin the pester that is specific journey. So I can I can put in a PR for this should be easy. So if you'll have some advice for that it would be great. I mean, while I handle the controller and common agent images. Yeah. Thank you. Okay. All right. So then we would benefit from additional testing but the whole like I think you said that the automation other than on the SSH agents or it was only the SSH agents that had a Windows agent test failure is that in general on all of them? No, it was on one image though point about the engines. We still need to get upstream image here to this first before get full CR running. That's why I focus on it first. Okay, because yeah, we need additional time. And yeah, this drop isn't working as well, like because of some issues. So we should give up actions. All right. Anything any other items on adopt open JDK 8 for Docker on Alpine. So we have discussed in previous meetings, potentially doing adopt open JDK on Buster and on CentOS on CentOS. Again, I think the in this case, I believe we're not yet distributing those. So Buster because stretch will be unsupported January of 2021. And I guess this leads us to a question of should what should our Debian plan be in general, given that the Debian project has announced the intent to release Debian bullseye in January of 2021. And they only support they only provide security fixes for current for stable and previous stable, not for anything older. And so beginning January 21 or sometime shortly thereafter, they will stop security fixing stretch. I thought they'd already done that. So that's good news at least. But if we're so if we're not pinning to a specific version of adopt open JDK, for instance, when they upgrade, we would get the upgrade to whatever new version is. Well, and I think that the pattern Oleg shown us is he's pinning strongly to a specific version of adopt open JDK's Docker image. And I prefer that as well. So does that does that mean that this discussion, the discussion of Buster or sent to us is actually no, I guess it's not irrelevant because they adopt open JDK provides a Buster image. Is that is that correct, Alex? I don't remember there. I don't remember if they provide a separate Buster tag. Yeah, let me do a quick check. Excuse my having to do the check while we're live here, but adopt open JDK. And what we're looking for is the top one is the the top one is the official. Oh, and we need unofficial. So, well, we have to use some of the unofficial images, but Buster is part of their official. Oh, it is. Okay. All right. So if we look at let's think it is, let's look first then at adopt open JDK. And these are the Docker official images. And if we look here, okay, I don't see in the filter tags, filter, Buster. There we go. Thank you. Okay, so don't see it there. How about Alpine? And we knew that Alpine is not yet official. We know it's right. It may not ever be. So the Docker official images are the ones that are built by the Docker people themselves. Right. The adopt open JDK repository or whatever you want to call it, are the ones built by. So that one right there is built by adopt open JDK. So it's not like it's some third random person. Right. So they don't have full test coverage being compared to official images. So at the platform meeting seven months ago, when we were discussing that, well, it was brought up as a main concern both in the J of Alpine images. And as Alex said, there is no guarantee that they will ever be in J. I mean, there's no other source for these images, unless we build them ourselves and test them ourselves, which I don't think we want to do. Yes. So for that. Yes. So like I'm trying to, trying to understand that one because I thought this was the image that we, this is the image that we need to use in order to do Alpine in order to. So therefore I think we are accepting that we'll use this. Yeah, there is one to do in the pull request. You reviewed this pull request to do six please references it as experimental ones. Right. And well, we couldn't do anything better. And let's be honest. I'm not sure what is better partial experimental test coverage, but by the open JDK, a conglomerate of multiple companies and contributors working on the baseline or in-house builds by Docker for which we have already experienced quite a number of problems. Yeah, my preference is that just yeah, my preference is to prefer what, what adopt open JDK even though they call it unofficial, I think it better meets our need. You know, well, anyway, the release is going out. So we agree I'm shipping them, but the person I don't expect degradation and test coverage. And if you're concerned about test coverage, we should rather focus on all on this coverage because we still have on the smoke test for the images. Right. Okay. So back to the buster question it was we think that buster is in this. Nope. Don't see anything there. So stretch. Okay. So they don't have a stretch in the chart. Okay. All right. So they don't specifically tag the devian. Oh, maybe it's devian. But it's Oh, should have thought of that. Right. It's probably not specific yet. So they don't call out that it's buster. But, but that that then indicates that we would be if we choose to use adopt open JDK as our base image, we would take whatever devian they're running, whatever devian is in their image because we would be based on their image. And the other thing we could do is propose or add additional tags to the upstream. I've done that for windows to request a specific tag for buster. They don't do a stretch image at all. And yeah, and I don't think there's any compelling reason for us to ask them for additional upstream tags. Let's just take what they've taken. So, so what we're really doing is, is this is it's saying that it's on buster and that that's likely accurate because you said they don't do stretch, but based on the adopt image adopt open JDK image, and it's bundled devian version, right? I mean, it's bundling some devian version and it's whatever that is. So in our example here, it might be, let's see, let's take one. Yeah. So for instance, if we took jre8u265 b01 devian as an example, and this would be the thing that would be devian basis. So really the reference to devian is just not relevant. Now on to the question of centos, we are delivering a centos image for centos7. Similar pattern, I assume that they tell us they choose a centos version and that's just implicit in the, yeah, here we go. So 265 and it's whatever centos version they're bundling at that time. No, we're actually not pulling from there right now from their image for centos. Okay, all right. From centos, not from adopt open JDK centos. Oh, got it. Okay. So what you're saying is the current build process uses a centos base image and then installs adopt open JDK. Oh, it installs page JDK. It just does yum install Java, Java develop. Okay. So it's installing, it installs, all right. So it sells JDK with yum with the package manager from the OS. And the same is true for our devian images, right? The current build process uses a devian base image. No, I don't think so. Oh, okay. All right. So our current devian it's from open JDK, a dash JDK dash stretch. Okay. So that's, that's a distinction between the two build processes there. So the current devian build process, the current centos build process uses centos image whereas the current devian build process uses the open JDK base image and doesn't therefore need to install a separate JDK using the package manager. The proposal there in terms of the transition to adopt open JDK, is it to consider using adopt open JDK as the base image for the devian build process as well? I think we need to find that because the one negative of using the package manager is you don't know explicitly what Java version you're getting. I guess it depends on whether we want to use a specific version of Java in our images or if we want to rely on the package manager. It would be the same thing for devian, right? We could use a from devian and then use that to install open JDK packages. I don't know if that's better or worse. Yeah. So what it, what it's at least highlights right now we are, we've got a disparity between centos build process that's based on core operating on the operating system image and the devian process is based on the open JDK image. The alpine process prior to O-Likes changes was based on the alpine image and so the new alpine image will be based on on adopt open JDK alpine image, right? Yeah. He put it on a specific version of the JDK. Right. Eight U and it was 262 if I remember right. Yeah. And there the question for me, I think that the the majority of our installations are using the devian, our devian based image. I'm hesitant there to say hey we'll accept breaking changes there. The number of potential people affected but if I remember correctly the even, even on our devian image we're not running a brand new, it's not running a latest version of JDK because the devian base doesn't offer us a or the open JDK base doesn't offer us a newer version. Alex I think, let's see if I look at that. The devian, oh the current devian. Yeah that was what I was just looking to see. I thought that the current devian uses open JDK eight JDK stretch. Okay. All right. So it's using there we go. Yeah. Okay. So you don't know what Java version that is or anything right now. Right. But I think that's one we should be able to find from Docker Hub, right? Just by searching for that. I need open JDK slash. No it's one of the, it's not an organization. Oh it is not. No it's part of the official Docker. So we go to the official Docker image. Open JDK. So it's part of what they call verified content. And then here if we filter for how did I, oh it's just search for the tag right. There we go. Yeah. So this one, this one is six months out of date. Therefore it can't be current because certainly we delivered, the JDK projects have delivered up two updates in the last six months. Let me do a quick check here. I think I've got a running installation here that I can do a quick check on system information that will tell us system information right there. Okay. And this, if I remember correctly, is running the current image. Yeah. It's 242. So it's not that far out of date. The current release is 262 or 265. So it's six months behind basically. Do they have a buster? That's a good question. I don't know. Let's look. So the question was does the official image have anything for buster? It had, so we need eight. JDK. Yes they do. And it's much more recent. So we could, so we could switch current Debian build buster to extend the life, the support life of that, of that base image right. But at least give us a way to pin to buster as well. Since adopt open JDK does not provide a buster since the tag. Right. Okay. Just as an idea, I don't know if we want to have different base images on the OS. I guess we already do. So. Yeah. So it seems like that might be less disruptive to users to switch the base image from open JDK stretch to open JDK buster than to switch to constructing it ourselves or to switch to adopt as the base image. Now I thought one of the reasons that we had considered shifting to adopt open JDK for the base image was worry that the Debian projects maintenance of open JDK might be less diligent than the adopt open JDK's maintenance of the JDK. I thought there'd been an episode, one episode some years ago where the Debian project wasn't able to keep up with all of the all of the open JDK changes. Even in the event when Maven 3.6.1 broke because there were issues in Debian. Right. Yeah. I think that was it. Right. I think it was it was Maven related. But but there haven't been issues since then. So I'm not sure that that's a compelling thing. But there was an episode. There was that one episode. So it really isn't yet about this. Yeah. Yeah. That's exactly what I was thinking. Thanks. You remind very well. What we really need is a is a technical discussion. And we have a forum to do technical discussions called the Jock the Jenkins enhancement proposal process. Yeah. So yes, wholehearted agreement. And and that's one of these. This is a an education point for me that our choice of which base image. Okay. Got it. So yes, that needs to be there. I'm not trying to turn it. No, no, we've got truly we've got to we've got to make the decision and the decision needs discussion and the Jeff is the place to do that. All right. Are there other things we need to discuss here other than that? Jeff's got to be created. And we've got to discuss that. I don't think we have any any issues that are burning things down on these images currently. We know that January 2021. 21 is a or let's say differently. Debian bullseye release is a major event because it will drop security support for our Debian base operating system image. They have Docker images for both of you. I think they do. Certainly the the the open JDK images do not have a bullseye image as far as I know. Let me just prove that. But I would be surprised if they did because bullseye is is not released. Oops bullseye. Yeah. So the the official images from from Docker do not have images based on Debian what will be Debian 11. Okay. So the crucial action there is action. We need a need a plan need a plan and completed work to switch before end of support end of security fixes. The other thing we need to think about is a rebuild plan for images because we use like app to install packages and things like that. Do we need to have a schedule for building images so that we can pick up updates to those packages for scary issues as well. So do we rebuild the images every month? Do we rebuild them every quarter? Which image is doing in drinks controller or agents? Yes. I thought it was both. Yeah. I guess the way to go is just set up the dependable. There might be tricky parts. For example, how do we update remote and other things. But for base images dependable to do the job. So dependable will change the base image that we're running. I thought Alex was also concerned about is so that updates to the versions of items that are that are specified by version. My concern is let's say that they, you know, there's a package that we're installing that has a security issue. Right. That's that's not going to be copied. Maybe we should have a security discount. Okay. Well, that's a that's also a very viable thing to consider. So security scanning. I mean, wouldn't that require us to build them on a schedule at least? Or is there other apps that check things? I'm not aware. So yeah, dependable would be checking dependencies automatically. Then when it discovers dependencies, it would be creating pull requests. This pull request will be built by Jenkins CI. And if there are related security updates, et cetera, we would be getting information in the security top on GitHub. Basically, any maintainer will have access to this information. So default behavior is that update is public. But the security details are private. Though if you want, you can disable a security pull request at all. And just get security controls. Yeah. And that would that would, for instance, offer us that would automate as an example, that would automate the update from JDK 8U to 62 to JDK 8U to 7 to conceptually, if that were the number they chose. But oh, like back to the question that Alex observed earlier, if the SSH package inside that Debian image had a flaw, that dependable won't detect that, right? That we would need something like security scanning or some other technique to depend on how security is currently working for Docker. Because depending on what is tool, it evolves. So I'm not sure what would you get now. And I'm not sure what would you get tomorrow. And nevertheless, if we really want to have deep security scanning, then we should just get the tool like Ensure or whatever now pipeline. I mean, we do scanning, just not on a continuous basis. Okay. And that's the kind of thing that Ensure or another tool is like at Snake or we'll do a deep scan looking for issues inside the image. Okay. And I'll show how deep this come, but the current situation. Okay. All right. Any any other topics we need to note with regard to image rebuild plan? It's yes. If so, like for instance, the the technique you're using with the Alpine update is well suited to be used with dependable, right? Because it explicitly names enumerates the version number inside it and dependable will offer a new version number update. It's not really a question of dependable because dependable, let's say it's additional feature. It's rather a matter of the previously usable builds. So while I'm still using Catech, but at least it provides some certainty what you said the image because otherwise you may easily end up with a situation that you cut an LCS release, then there is a Java release or whatever release happening in peril. So that you ship one of the just use one version of Java, another version of use another Java, or you might be shipping conversion, which wasn't tested by your continuous integration environment. And you discovered it from the one you cut the release because released pick up picked up another version from the same tag. So in the current state, our official packaging is exposed to all these issues. Opinion conversion is what I would highly recommend for any use case of Docker. And yes, I do have strong opinions about that and dependable is not the main reason. I see. Okay. All right. So it's it's more about build repeatability, your preference towards explicitly enumerating the version numbers inside the component inside the the from line of the Docker image. Okay. All right. Any other items we need to discuss there? All right, Alex, anything we're nearing the end of our time, anything you wanted to report on proposed deprecation of the stretch images? Is this the same thing due to yeah, stretch retirement or stretch end of life? We actually already have buster images for the agents. Whereas it looks like we don't for the controller. So it would just be in this case, not publishing them anymore. Is there a is there anything we can or should do to alert alert people that this thing is reaching end of life? I'm not sure how we would communicate to consumers of the images of stretch of the Docker agent stretch images, right? I mean, they've captured an image. There's there's not really a way for us to tell them, hey, we're not going to deliver new versions of this. There is a way for us to do that. We have entry point, which includes a script, and we can easily add a warning to this script. So that every time you launch this entry point, you'll get the warning and console that this image is deprecated. Yeah, it won't cover 100% of use cases, but it will definitely cover the most common use cases for that. Good. Yeah, if you want to go a few days, you can do the same, for example, on the remote inside so that it also appears in the build blocks. But for build blocks, you will really need to tweak the moting. Well, unless Docker plugin or Kubernetes plugin recognize these messages. Oh, I see what you're saying. What you're saying is, if we taught remoting to detect that warning and raise it to the user, I'm not sure I could you describe further what you mean there? It's even easier. For example, you at Java system property. And in the remoting, you can just read the system property and display it in the system block. So you don't need to invent any new mechanism. Okay, so that would need to add a property to the agent image. And we would need to extend remoting to show that or? Yeah. So if you want to provide good user experience, then yes, you would need to change remoting. I see. Okay. Well, there might be other approaches. But yeah, it's not exactly a huge patch. Got it. Okay. And this patch can be actually useful for many other use cases. So it would be definitely willing to support it. All right. Okay. So anything else on deprecating the Docker agent stretch images? Okay, next topic we had listed was GitHub app authentication on ci.jenkins.io. Oh, like I think there the report is it's in use. It's being used and working. Yeah. So definitely we could do a longer demo. But while I don't think it makes much sense, because next week we will have a presentation by Kezia including ci.jenkins.io. So just join online with us if you're interested to see the details how it works on little plugins. Yeah, ci.jenkins.io was switched. So now we've got a higher API rate limit, and also pipeline libraries, etc. Now use GitHub checks API for reporting as well as multibranch pipeline. So there are some issues we discovered. For example, duplicating reporting for Java doc and other things. So we like an update of GitHub checks API plugins. But overall, it seems to be working. Excellent. Okay. Last item using plugin installation manager and Docker images. So this is in preview preview from Tim Jacob's poll request. Have has the image been released with that preview in it? No, we agreed to delete until there is a security release. And they can the current situation, I'm not sure whether we agree to not but I think we need to delete a bit more. So we firstly ship a doctor from GTK changes. And after that, ship the preview, though I would be interested to have it in the next weekend. And I believe that we will have it in the next weekend. Right. Okay. Well, so yeah, when you say weekly, oh, right, week, the Docker image based on the weekly. Is that what you mean? So, which is 2.253 will be the next weekly. Okay. Great. Anything else we need to put on the list for today? Oleg, do you want to give us a current status on the alpine release process you've been running? Okay. So well, quick update. We have a release of Docker agent base image. So I will place the link to the chat. But yeah, right now, Docker Hub should be building this stuff as well as trusted CI. Same for Jenkins controller base image. Also, it's building. We still need to see what will be the result for that. But yeah, the image is running. So at least latest versions should be updated. I'm not sure about the text, but this is something we plan to verify now by plan. Then for stage built agents, I'm still waiting for pull request to complete because Alex updated faster before that it was filling on Windows. So we need to pick up a fix and the release or maybe do a blind release with filling CI. But yeah, right now it's still running. And yeah, for inbound tangent and for GNLP agents, repositories, we still need to do the stuff. So optimistically by the end of the day, everything will be released. But it's not something like I will finish it in one hour. Excellent. That's thank you very much. Thank you for your heroism on it. Thanks. Thanks. All right. I think that ends our topics. I'm going to go ahead and close the session. Anything else before we end? Oh, thanks, Mark. Thanks everybody.