 Today, we have an ad hoc session. Marco asked me to describe how we do the release for Jenkins Docker images. So today, we will just have a short walk through of the release process, and we will get it published on the documentation side. Okay, do you see my screen? I do, thanks. Okay, just quick introduction for those who don't know the structure of Docker images. For Jenkins agents, we have two main repositories. One is Docker slave, another one is Docker general PSlave. Disclaimer, I'm going to rename them soon, so they will be finally agents, but it's a bit delayed. So Docker slave is a base image, which basically packages are remoteing and few other components, and you can see that there is a bunch of platforms that are being released. And there is a second project, Docker general PSlave, which actually provides inbound connection support for Jenkins. So general Piki, it's not Java web start, it's just a historical name of the protocols, but what it really does, it connects agent using standard parameters. So basically similar to how we connect remoteing Java to Jenkins masters. So it's advanced griper being compared to Docker slave. Okay, we have a few Docker files, all of them are more similar. We use Jenkins slave, this is this repository as a base image, and then we get it released. You can see that now the version we consume is 4.0.1-1, so what it means, we use a remoteing-based version, there is a remoteing project. And here you can see that there is a change log. And the last release of remoteing was 4.2, which fixed one issue, which impacts installation of the service. So it was a regression on the Jenkins core, it's not a problem for us for Docker images. So we don't bump immediately under smart commands to update it as a part of this demo. And what was the ask, we just want to release the current version. So our state that for Docker channel P agent, we still don't have the recent release. So here we'll use a release drafter to make change logs, and you can see what changes we have staged. So basically once we haven't been released from the master branch. And here we have enabled WebSocket support. So it's a JEP, which has been recently released in Jenkins core. So we still need an engine. There are also other things which we need to process. So this is what we will be releasing. How the release process works here. This repository has continuous delivery. You can go to Docker Hub and on Docker Hub you can see that there is a number of labels, being submitted. So just here. And there are latest labels. So latest labels being delivered automatically every time you'll notice the pull-to-quest. So it's full continuous delivery. And there are also tagged labels. So for example, 3.40.1, JDK 11, all fine. This is what we still need to release. So to have a tag for the new deployment. In order to do that, what we need is to just cut a new release on the GitHub side, because the rest will be handled by Docker Hub. So currently our build runs on Docker Hub. There is a plan to move it to CI Jenkins or other instance. If I tell you about Docker Hub, that's what we need. So here let's check that everything is ready to be released. So again, the version we will be picking up is 4.0.1. So we can start editing a draft. So since I'm doing the release, what I'll do, I'll just create a new draft. So the version for us will be 4.0. Promoting version dash one. So how we prepare this version? There is documentation in this repository, I believe. But basically it's a base version of remoting we use plus one number which we use for incremental versions based on the same baseline, because we still need to deliver changes. In some cases, yep. So Oleg there was not already a 4.0.1 dash one. Oh no, it was 3.40 dash one. Thank, sorry, it's right. So the left-hand side, the remoting version number, this is the first time we will have published a release with the left-hand side 4.0.1. Thanks. Exactly. Yeah, so we will still need to copy edit it. So I'm just copying what we have now in the release wrapper. So you can see that this draft is not complete because some requests haven't been tagged properly. And we will need to review them. And also maybe release title. So let's double-check what is our policy because we'll sometimes forget it. So we use just version and name here. So without V prefixes or whatever. And it's important to keep this version in because we have repositories which use dependable to pick up dependencies and they need this information. So let's take a look at our release again. You can see that there are multiple images here and we need to double-check that everything is fine. So here we have multiple versions. All of them should be aligned. So these are three images which we push to the production and another ones are Docker ones. So Docker, sorry, windows images are now experimental. We still want to ensure that they are more or less aligned but here you can see that they use late version. But what it means is that we don't really need to do version management here. Each time, so latest versions get released automatically every time so it's not our problem right now. We basically control only these images. We know that they're ready to go. So let's just prepare. Here, yeah, we have a change log which we still need to finalize. So these changes are ready to go but let's take a look at this one. So it is timeout in netcard helper. So you can see that it's test automation. So basically it's an internal change which doesn't impact users. So we just put it here. And this change is going to be a bit more complicated because it's promoting. So here you can see that we basically bump the dependencies and we already have Docker slave repositories. So we can just take a look what is the change log there so that we can pick it up. And then change log there has been already prepared. It's update to remote and for the zero of one to pick up minor improvements for the client side. That's it. It was one of issues we had because it was marked as a security release but it's not a security release for agents. Something for the master side. So we can put a significantly low priority message. So I just copied the release text and I got the proper pull request reference and I think that's fine. And this is actually dependency update. So we need to take another category for that. I'll just copy it from another change log. And now if we had labeled that pull request as a dependency update, it would have done this for us automatically but instead you copied it for us. Yes. Well, it wouldn't create the same change log automatically because you can see that there is reference to remote and change log and other components. So it still requires some copy editing but if everything was categorized and properly and the pull request titles have proper issues, proper text we have spent this time. Yeah, business as usual. So this release is ready and I think we can just click a button, okay. So I'll just, yeah, I just published the release. So, and my experience has been that even after I've published the release I can still make editorial corrections to the release to this change log. So it's not a permanent or I'll never be able to change it again. Yeah, you can edit the release. So what happens after you click publish? First thing that happens that notification goes out to your users. So it means that this text already goes to your users but you can edit it if you need. The second thing which happens here is again we have continuous delivery. So the doctor will pick up these bills and it will start executing. So here let's go to the bills section. I'm not logged in but I believe that it should pick it up. So you're in slash JNLP dash life, isn't it slash Docker dash JNLP dash slave? Is this a different? Yeah, well it's the same repository. It is, okay. We truncated Docker prefix from Docker Hub because everything is Docker there. Okay. So you can see that there is no bill pending but I suspect it's because I'm not logged in. So just a second I'll log in and then I'll share my screen again. So meanwhile, do you have any questions Mark? So the process that will happen now is all going to happen on Docker Hub. The actual construction of the images and the publication on Docker Hub. So they will execute the bill. They will actually get the bill to the Docker files and publish the tags. Yeah, that's right. And do we have any control at a scripting level? Everything is just, they execute all of our Docker files? Yeah, that's right. So I'll share my screen again. Okay, you can see that now I have logged in and here we can also see some information about the bills and we can just go to the manage repository to see whether the bill was really executed. So here you can see that we manage front end. We have a number of bills in progress. So basically we have bills for opine, for JDK 11 and for base image, which is a DBIN. And this bill is a bill executed. So if you have permissions, you can check these bills. Yeah. So regarding automation for bills, the automation on the side of Docker Hub is quite straightforward. So we have three baselines being released here. So here's a branch. So master branch, it gets released automatically. So opine, Docker, et cetera, and then they get the latest labels. And again for tags, every time you take a release the event goes to Docker Hub and Docker Hub executes the bills. So these are the bills which have been executed right now. Okay, I'm not sure what has happened. But yeah, the thing that all the bill processes managed by these files. So there is no additional magic inside. It applies to almost all official Jenkins images. So if you use other images, which are built on Docker Hub, the process is the smallest, the same. So agent images, Jenkins file runner, all tools like the plugin compatibility tester, then all of them are the same. So let's take a look what happens with our bills. This particular bill takes a while, mostly because of scheduling, but you can see that the version is already deployed for the base image. So you can see that the bill has been executed and what it means that all users can now start using it and they can enable with WebSocket support that they need. Okay, and we can just check it just in case. So it's not something I always do because I'll share what's pretty well, but yeah. Okay. Again, sleep, temporary. Okay, so let's let it download and here for example, we can just use a version command. It should be supported in this image. Well, and just the fact that you're able to do a Docker pull tells me, okay, the auto build on Docker hub completed, it's there, it's been tagged and they're labeled and therefore ready to go. Yeah, so the only thing is to ensure whether it's what you actually need, but yeah, you can see that there is help and help already references WebSocket flag. So it's definitely the version we need. You can double check it if you want. So commands are not passed here, that's easy, but yeah, you can see the version. So yeah, we've got the release we needed. Excellent, thank you. So does that conclude everything then? The release is now done. No other items need to be done? No. So the only hint that it's better to copy it to change logs before you merge pull requests because our change log automation is based on labels. On labels and on a pull request text. So if you spend some time before merging or if you require submitters to prepare this text, we just save this time and prepare the release. Okay, so that's it. Thank you very much, Oleg. Thanks, thanks, thank you. Yeah, thank you too. I will archive this and submit a pull request to the Docker JNLP slave repository with a copy of a pointer to the documentation. Thank you.