 That way we can host it later. This is the Jenkins Newcomer contributor track in the Jenkins contributor summit on the 25th of June. Thanks everyone for joining us. So let's continue our session next. Today what we'd like to do is we're going to do a fast introduction to Jenkins. Then I'm going to spend some time talking about contributing through Java in Jenkins because a large chunk of the code is Java. We are looking for Java contributors. Then we're going to have Diraj talk about what it means to contribute in documentation based on his experience doing the weekly change log. Then Aditya is going to share his experiences contributing to infrastructure. Then we'll go back to Diraj for a discussion of his contributions in React.js and question and answer. Now, given that we're a nice small group, you should feel free at any time to unmute yourself and ask a question. Don't be shy about worrying, oh, I might interrupt. No, this is intended to be conversational. We would love to work together. We will try to do breaks at about every 50 or 55 minutes just so that we don't get too weary of each other and just so you don't get so weary of hearing any one particular set of voices. After we've completed this segment, we've got some other things planned as well, but we'd like to then tune those to meet your needs. So let's talk first about during the contributor summit if you want to use chat or you can unmute. Afterwards, you're welcome to join this get or chat channel, newcomer contributors, and let me paste that into the chat so that you've got it. Just a minute, let me find the chat first. Chat is right here. Okay, and now the get or chat is, it's easiest if I do it like this. The get or chat for new contributors is there. Okay, great. All right, so first a reminder, what's Jenkins? It's an automation framework. It's the most popular CI CD tool, particularly in open source. It is a very large community with more than now 1700 plugins that make it do what it does. It's an automation tool for coding, for building, for static analysis, for release and deploy. It does the typical things you might expect like check out source code, build that source code, analyze it for issues, test it and publish results, deploy artifacts, maybe even all the way to production and notify people. It's big. In 2019 alone, 67 releases, 5,000 contributors, 111 countries. There's lots going on in Jenkins. However, it's amazing what amount happens with one and two people at a time. Comparatively, we are large, even in the scope of other projects at CNCF and CDF, you see here diagrammatically, yes, the Kubernetes project is bigger than the Jenkins project, but Jenkins is larger than most other projects in the CDF and CNCF space. Now under the hood, what is it? Well, it's a bunch of GitHub repositories on Jenkins CI. And if you want to do infrastructure, it's on Jenkins Infra. The core is on Jenkins CI slash Jenkins, the Docker images for the controller on Docker and all the documentation is at Jenkins.io. So it's all maintained as code. We like how we do that and we encourage pull requests to improve it. Now in terms of the technology stack, many, many repositories, top languages are Java and JavaScript with strong influence from Groovy and tooling in Golang and Ruby and other scripting languages. Platform-wise we're on Docker, on Kubernetes, on Linux, Windows, Mac OS, FreeBSD, OpenBSD and our documentation is maintained as code as well and mark down and ask you doc. Now my motivation today is to try to persuade you to adopt a plugin and adopt a plugin. Adopting a plugin is a process that the Jenkins project uses to allow people to maintain plugins across the world. So what we've got here is individual maintainers, one or two or sometimes three are the ones who care for an individual plugin and those maintainers release the plugin, they update it to use new versions, et cetera. Well, one of the things we need is more maintainers because we've got over a hundred that are ready to be adopted. Now, first challenge is we need to overcome your sense of imposter syndrome. Oh, I can't do that. Then we're gonna talk about how you can find which plugins you can adopt, then you send the request to adopt the plugin and you start improving it. It's actually a relatively lightweight process to do this and some of these plugins are so lightweight that you could adopt them and only spend on the order of minutes or maybe an hour a week and still be a very successful plugin maintainer. So this is not a life commitment. This is not an, oh, I have to do a whole bunch of things. First, yes. I have a question. Go ahead, Dheeraj. So in the previous slide, if you can go back. Uh-huh. So there you mentioned that improve the plugin and release the improvements. Can you give me one more examples on how we can improve a plugin? Absolutely. Yes. So for instance, one of the things that I think it was actually Jonathan mentioned is he's been maintaining a plugin just keeping it up to date. And one way to improve the plugin is to update it so that you're sure it runs with and depends on a modern Jenkins version. So you might update the POM file to use the most recent POM. You might update its dependencies to depend on more recent, more modern libraries. Those are very valuable improvements that help reduce the load on others and reduce the risks and the debt that exists for a project that has a nice long life like Jenkins does. So Dheeraj, did that answer your question? Yes. Thank you. Super. And thank you for asking questions. That's exactly what we want. So one of the things that I wrestled with as I was considering becoming a plugin maintainer is imposter syndrome. This is a condition where people mistakenly downgrade or deprecate or deride their own skills and their own ability to learn. And I'm here to persuade you that you should stop doing that when it comes to adopting a plugin. If you're willing to learn, if you're willing to ask questions, if you're willing to seek answers, test your changes and help others, then you are ready to adopt a Jenkins plugin. There are plugins that you could adopt if you're willing to do basic, fundamental things like this. Now, if you say, oh, I can't do those things, all right, then maybe you shouldn't adopt a plugin, but most people with technology experience could benefit themselves and others by adopting a plugin and caring for it, spending 10 minutes, 15 minutes, 30 minutes, exploring it to understand how it might be improved just a little bit. So let's talk first about some of the plugins that are available for adoption. So there are API plugins. Now what an API plugin is in the adoption list is it's a plugin that is a Jenkins representation of an existing API component. For example, the Apache HTTP client is a released library that's shipped by others, but in order to make it convenient to use for a Jenkins developer, we have a Jenkins plugin whose whole job is to bundle that library. It's a pretty simple task to maintain the API plugin. You watch the API that it's bundling when it releases a new version, you update the plugin and release test it and release a new version with that updated library. So Apache HTTP client right now is on version 4.13. You would watch and when 4.14 releases, you choose to update the POM file, one line, build it, test it in your Jenkins instance and submit a release. And now you've released a new version of the plugin. Likewise, there are build utilities. One of these may be something you're already using where you say, oh, that matters to me, I use timeout or oh yeah, I use the configuration file provider or you know what, promoted build is important to me. Well, guess what? Adopting those is a way to serve your community, serve yourself and help others. Likewise, very popular are the SCM plugins if you're a subversion user, there's a motivation to consider adopting the subversion plugin or maybe your CVS user or a TFS user or a clear case, any one of those plugins is looking for a maintainer. I maintain the Git plugin and the way I got there was I started by writing tests for the Git plugin trying to avoid regressions. And after writing tests for a while, people said, hey, should we just give this guy permission because he keeps submitting all these tests? You could do that. Now there are more things, more plugins that could be adopted like on Windows, if you're a Windows user there are Windows specific things that could help others and may help you as well. Maybe you use MS build and you need the MS build plugin or you use Wix to build your installer or you depend on the Windows management install the WMI layer agents. All those are looking for adoption. Likewise, there are admin tools that you may use. Maybe you use one of the backup plugins or the job config history or maybe you're a cloud user and one of these cloud plugins that's up for adoption is a candidate that you should consider. Likewise, there are test tools that need to be put up that have been put up for adoption and are ready. So all of them give us a hint that there's lots that you could do if you were willing to adopt a plugin and help us. So now let's take a minute here and look at the process. And I've got a, whoops, I need to go back one. So this is what we do. We follow this page that gives us instructions on how to identify a plugin that's up for adoption and then adopt it. And it talks about, hey, you send an email to the Jenkins developer mailing list with a link to the plugin you want to adopt, a link to the pull request that you'd like to deliver, if any, your GitHub username and your Jenkins account. So now how do we find plugins that need adoption? Let's go back and let's locate them on the plugin site, Jenkins plugins. And if I remember correctly, what we do is we ask about adopt. Nope, that's not right. Let's see, it is, I think it's label equals. Okay, let's find CVS. We'll find it the easy way, click here. And I'm going to click this label, adopt this plugin. There we go. Come on. So when I refresh this page, we're going to see that list of 111 plugins that are up for adoption. Let me put this into the slide, that really belongs there because you need to know where to find the plugin to adopt. All right, I guess that another way is that you could go to your Jenkins plugin section and then if you are using a specific plugin that is requiring adoption, you will see on their install section, that's the more that way to find it, right? Oh, that is Marcel, that is a brilliant way to find it. Thank you for highlighting that, that is absolutely. So did you catch what Marcel said? He noted your Jenkins installation will hint to you the things you might consider adopting. So what I did was I went to the Jenkins dashboard to manage Jenkins, manage plugins and under installed. Now look at these nice big boxes that tell me, oh, hey, the Apache HTTP components client 4.x API plugin is up for adoption. This is one that I was describing, right? So you see it here and this is a great candidate. Maybe you say, I'd like to know more about that plugin. So you open that link and here is all the discussion about that plugin. Oh, I'd like to see it's GitHub repository. There it is, ready to go. Okay, what kinds of changes have happened recently? All visible from here and waiting for you to get involved to adopt it. Excellent, Marcel, thanks so much for pointing that out. So let's look at marks at my installation to see just how many of the plugins that I actively use are up for adoption. So I've got Apache HTTP, authorize the BitBucket branch source, the build timeout plugin, conditional build step, config file provider. This one's actually quite valuable to me. I like that one. Configuration slicing, oh, I love this one. And I would love for somebody to adopt it because it lets me with one set of clicks modify the configurations of many, many jobs all at once and gives you a good hint of the kinds of plugins that are up for adoption. Marcel, thanks again for pointing us that way. That's a great, let me put that in the slides, is look at your own Jenkins instance, manage plugins installed. Excellent. So the process that was described there, send an email to the Jenkins developers mailing list is pretty simple. It's not a very high bar. You can just ask, hey, I'd like to be made a maintainer. Now with some of the plugins, they may ask that you first submit pull requests to show that you're interested. They, that's a fair thing. And okay, it's a great way to get involved. Any other questions so far? Oh, hello, Mark. Very good. Hello. This is the ratio here. In context to the skills that is required actually to develop a plugin, can you please tell me what specific Java skills do we need? Good question. So what specific Java skills are needed to maintain a plugin? So if it's okay, I'm gonna tell my story as a way to answer your question. So I was a manager, warning, morning manager, I said manager. I was a manager of a team of software developers. I had been managing for many years and therefore did not write code day to day, right? I did not, but I was interested because I wanted to be sure that the particular plugin that caught my interest was had more tests. So I started personally writing tests, but I had not done active Java development. I had little or no experience in Java IDEs. And I used my beginnings of adopting the plugin to learn those things. So if you're willing to learn about Java, if you're willing to learn about how to use Maven, I had never used Maven before starting work on the Jenkins Git plugin. I had all those things were brand new to me and I used this as a way to learn them. So in terms of the bar to actually do the work, it's quite low. Now, yes, if you don't have interest in it, if you say, no, I want to do JavaScript, then you probably should not adopt a Jenkins plugin. It is Java development. Siddesh, did that answer your question or would you like to explore further? Thanks Mark, thanks for the answer at this point. However, I succeeded to this question and I also have another question, like Jenkins extensions are sometimes built using Groovy as well. So is knowledge of Groovy also sufficient or is it only pure Java that we need? So generally a Jenkins plugin will not be built with Groovy. Many people use Groovy to create pipelines. They use Groovy in very interesting ways, but a plugin will generally be a Java component rather than a Groovy component. Given that Groovy and Java syntax are quite similar, I didn't find it difficult to learn Groovy when I needed it, but in my case, I had been a maintainer of a plugin for many, many years before I even did anything with Groovy. Thanks Mark. All right, and anything else along that line, Siddesh? Yeah, just a probably, go ahead. Sorry, sorry, sorry guys. Just a very nice question, because I'm very, very new to this particular topic, but I'm very much interested in getting along because I have been using a lot of plugins. There has always been a kind of enthusiasm as to how the plugins are getting developed. And I think this is the best platform that I can get to most of the knowledge. The question that I had actually, Mark, is initially, obviously, like you showed the materials as to how to get and adopt a plugin, basically. But there might be instances where, initially, we are specifically myself. I might need some kind of a hand-holding. So is it possible that I can reach to you or someone else to understand the process, basically? So once we get an update to it, we can contribute more. There absolutely is, very good point. So if you have a question related to, hey, I'd like to adopt a plugin, you could either, so let's put a note on that. You could either, let's see, where would I best put that? Let's find, how about, how about we'll just put it right here? So one is the developer's mailing list or chat on newcomer contributors, Gitter Channel. So, and that is at this location. So I'm gonna go ahead and open it up. And it's Jenkins, Gitter here, and here is the newcomer contributors channel. And what that is, is it's specifically dedicated to helping people who are brand new contributors. And so there you'll find folks. Now, if you've got a very specific development question, the Jenkins developer list is a great place to ask your question. If you're feeling like I did initially, if you're letting your imposter syndrome kick in and you say, I'm not sure I wanna ask a question in that big of a group, the newcomer contributors group is quite small and very comfortable. Thanks Mark, please. Can you also share the slides across, you know, you can, you can, Oh, yes, yes, absolutely. Oh, very good. Thank you. I'm gonna paste the slides, the link to the slides in the chat. Sorry about that. Slides for the session are here. There, very good. Now, Valentin, I believe you also had a question. Yes, I had a question. I have noticed that some plugins have forks on GitHub. I explained it and this does confuse me. For example, I saw as an example, I will name a SonarCube plugin, SonarCube plugin at Jenkins. It's a fork of Sonar scanner Jenkins. So if I wanna make a pull request or something like this, where should I start? Very good question. Okay, and I'm showing, I'm showing on my screen an example that's not the SonarCube example you did, but an example that I deal with. It's okay. So I think what you're highlighting is this text right here. Yes, yes. Right? It says, hey, wait a second. This thing is forked from some, and that while that message is accurate, if we can open this up and we'll see just what that means. So yes, the Jenkins CI Git plugin repository accurately was forked from Nigel Magnaes, Magnaes Hudson Git plugin. But if we look at the commits to that one, what you'll see is the last commit to that plugin was 11 years ago. Yeah. So what this is, what you're seeing here, this forked from is just an artifact of the history of the plugin who its original author before they were ready to bring it into the Jenkins organization. So the simple answer is you can ignore the forked from. And in 99.99% of the cases, that is the exact right safe thing to do. So ignore the forked from and follow the contributing directions that you'll find for most plugins in their contributing file, like this one, where it says, this is where you should contribute and this is how you should do it, those kinds of things. Contributing, okay. Does every single plugin has this contributing notice? No, no, we hope most of them do, but that relies on the maintainer to have created the thing. Okay. Thanks. Did that address your question? Do you have further questions? Yes, sure, sure, for sure. Thank you, all right. Sorry for when dropped. Yes, Akira. Yeah, I have to go. So see you later. No problem. And I'll see you on other drugs, see you. Thank you, thank you, thanks very much. All right, so back to the idea that we want to encourage adoption of plugins. So you find the plugin you want to adopt and remember this is the part where you have to overcome the imposter syndrome thing. Oh, but I can't adopt a plugin that's much too popular, much too big or much too narrow. Stop making excuses and just acknowledge that it's a good thing to, yeah, okay, maybe I'll give a little bit of time and see how it goes. So when you adopt the plugin, you might ask, and this was something that D'Raj asked, what are some things that you might do initially to a plugin? And so, Jonathan, I'm going to sort of target your plugin as one example of this kind of thing because it's a valid question. Hey, I've got this plugin that I use, but what are the things that might benefit me to do it? And so one is you can simplify your life dramatically. Now, I've got to be able to highlight. If you use dependabot to track dependencies, this is a little bit of automation that will cause automated processes to run on GitHub periodically that look for new versions of your dependencies. I love this thing because what it does is it tells me when the plugin I maintain has a new update. So as an example, let's look at one of the plugins I maintain is called the platform labeler. And I love what this thing tells me in terms of pull requests because I will get a pull request that says, let's look at closed pull requests. Oh, one of some of my tests depend on a Docker image and this bump the Amazon Linux Docker image was offered to me by dependabot without me doing anything. I did absolutely nothing other than configure dependabot and it has suggested, hey, Amazon upgraded their Docker image. Oh, Ubuntu upgraded their Docker image. Ooh, Alpine upgraded their Docker image. Each of them with no effort on my part, dependabot just helps. So this is a great one, dependabot is wonderful and there's this entire video here on how you use dependabot for Jenkins plugin development. So first point for me is use dependabot or enable dependabot and that's if you say, oh, I'm not sure I'm ready to adopt a plugin. That's also a good first pull request because the maintainers should be delighted to see you suggesting that you use dependabot. So any questions on dependabot or any experiences you'd like to share from your use of dependabot. Okay, next thing that you can do to simplify your life as a developer is simplify the changelog maintenance with a release drafter. Okay, release drafter is again a little piece of automation that watches the pull requests that you merge and proposes changes to the changelog so that other people can see it and automatically publish it so that you can automatically publish it when you're ready to release. Oh, just a minute, I'm getting pinged. Oh, yeah, okay, that'll wait. All right, so have any of you had experience previously with release drafter? I'm gonna show you an example of release drafter and show you just why I am so pleased with it. Here's the experience that I have with release drafter. Notice this formatted, let's shrink it a little, oops. This list of what's changed in the Git plugin was all created for me automatically from the pull requests that I merged to the plugin. I didn't do anything to create this, what to me is a very attractive page. It assigned things to features and improvements to dependency updates, to documentation updates all through the magic of release drafter. So it's a great thing to do as a proposed change for a plugin you're adopting. Likewise, this one, use the Jenkins plugin bill of materials is a great way to simplify the maintenance of a plugin and simplifying is really a good thing. So this page talks about how you use this, how you add this little snippet right here and then you start taking away specific version numbers listed in your plugin and it's much, much better to maintain. So Jenkins bill of materials, track dependencies with dependabot and simplify your change log management with release drafter, all good things to do to contribute to a plugin. Likewise, you could move the documentation into the GitHub repository, many older plugins. So Jonathan, I would guess your plugin probably has documentation published to the wiki, right? If I think about where its documentation is, it's probably on the wiki or some or is that correct? No, I've been actually trying to find it. It appears to have fallen off, right? And so I can find it in GitHub, but I can't find much of anything in most of the last step. There's like five or six years old. And this video can guide you how you can convert so that you keep all the documentation in GitHub right next to the source code. So you revise the documentation as you release new versions of the plugin. And I tell you, I love documentation as code because it lets me assure that we release plugins that are documented well. Then you just release the improvement. Oh dear. Okay, just a minute. Okay, I've got breakout sessions. Dear Raj, I'm going to make you the owner of this session. I'm gonna make you the host temporarily. I need to go off and check to see what's going on in the other sessions. It appears that I've broken something and I'm really sorry. Can you all pause for five or 10 minutes or Dear Raj, if maybe what we do is would you be willing, Dear Raj, if we went right to your segment, but you'll need to share your screen so that they can see the slides and I'm gonna make you the host. Do you have the slides available? Yes, yes, I do that. Okay, that way I can go see if I can help with whatever mess I've created in the other channel. I am so sorry. Clearly I am not as skilled at this as I should be. No problem, Mark, we'll take over. All right, so Dear Raj, I'm gonna make you the host and you should now be the host as of now. Yes. And I'm going to drop off to go see if I can help with the mess I've created elsewhere. Sure. So I'm going to stop sharing and Dear Raj, could you share your screen before I leave? That way I know that at least that much is working and then I'll leave and. Yes. Mark meanwhile, I think there's a question for you in the chat. Oh, there is. Okay. Yeah. Okay, so Jyothi, the question was, is adopting a plugin, maintaining the GitHub repo of the plugin? Yes, ultimately that's what you do is the way you adopt a plugin is you begin submitting pull requests or other changes to the GitHub repo of that plugin. All right, I'm gonna go ahead and exit and see if I can go be of assistance to fix whatever mess I've created elsewhere. So I'm assuming my screen is visible. It is, that's great. Yes. Awesome. Okay. So let me start. So my name is Dheera Singh Jyothi as I told you before and right now we're going to learn about the change logs, weekly change logs. And I'm going to share my experience of working with it and how I went about it and everything from start to end. And so as you can see on your right side, this is a snippet of the weekly change law that we at Jenkins write. And the reason behind writing these change logs is that we release a new Jenkins release on a weekly basis. And on each release, we have a new bug fix or a feature enhancement that the developers do. And what this change log does is it compiles all the things that the latest version of Jenkins shows and releases and just beautifully documents it on the screen. And if you want to check this out right now so you can go to your browser and just write down Jenkins.io slash change logs. So you'll be able to see all the change logs. So now, so these are basically very user centered description. What I mean by that is that each of the point is written in the order of priorities. And there are some set of rules which we follow in order to place all of them. So the main aim of our aim is that the developers should spend less time to understand everything. And at just a one glance that they can understand what is new with the current release. So as I said, it's released every week and it's definitely human edited with tooling help. So I use a tool, it's a Docker tool which is used to compile all the pull requests that have been submitted right from the previous change log that was released. And then I edit it in the form of, by following the style guide where I was mentioning the set of rules and then just compile it and then send a pull request. So, yes. So this is a very important part. Like I really want to share my experience with everyone so that if anyone is interested to know the process behind it or they want to contribute that then it will be really helpful for you. So I started to join docs office hour. It happens every Tuesday and Thursday as well as optionally, Indian standard time. So I joined them and I interacted with Mark and everyone and then I watched some videos where Mark was showing how to write change logs and all the videos are available on YouTube channel as well. So you can watch me as well doing all those change logs one by one. So it will be very easy for you to refer them and just reveal the recordings and then generate it on your own on your local machine and then just simply submit a pull request. And it's not complicated. That's what I'm trying to say here because as Siddhashti also asked us about what's the requirement of Java that we need to have in order to contribute to plugins. So similarly here as well if you talk about the requirements here it's not something you need to not to be an expert. You just need to have wish to, you know do some meaningful contributions there. So it will be really great. We can use your help here. So yes. So now I will request Adithya to share his experience with us. Thank you, Dheeraj. Before that, there's another question for you in the chat by Jyoti again. Yes. So I'll read the question for you. Can you share how can I join docs officers? Is there any meeting link? Awesome. So there's a Gitter link. I'll... Yes. That's a great question. So if you can see my screen then, okay. I'm trying to understand how to... We are able to see the Gitter channel if that's what you're trying to do. Yes. So this is the link that you want to click on and you'll be redirected to the place of Gitter channel for Docs Office R. Is there any meeting links? Yes. So also, you would also love to know about... I think it's calendar. Yeah. Evens calendar for Jenkins. So this website tells you all about the upcoming events that we have. And it will tell you that when is going to be the next meeting for Jenkins Docs Office R. So currently we are here. So you can see there's a lot going on today due to Contributor Summit. And so you'll be able to see everything here. The details of timing and everything. So I'll share the link of this as well in the chat. So this is the calendar that you can refer. Now, thank you for the question. Thanks. So, okay. Yes. Aditya. Thank you, Aditya. So hello everyone. And I've been infrastructure and advocacy enthusiast. Direk, please move on to the next slide. So I'll give you some background information on how I started participating and contributing to Jenkins Infra. So one day I just actually randomly attended the Jenkins Infra meeting and it was Mark and Gareth. I think they were discussing about some downtime in Jenkins. And that is when I saw how youth Jenkins is and the slide that was shown by Mark about Jenkins by the numbers. It was actually, and once you get the feel of how they are actually managing such a huge thing, it's awesome. It just blew my mind that I was like, okay, now I want to contribute and learn how to contribute to this. So yeah, the Jenkins Infra has a huge code base. Jenkins has more than 300,000 installations. And it is really awesome when you see how it is distributed around the globe. And every time there's a download, it finds the nearest mirror and downloads from there. So it's just awesome. I cannot stop saying how mind-blowing I was and how awesome it is. So yeah, joining the infrastructure meeting, the calendar link is shared by Dheeraj in the chat. I think that would be the first step. And that is the step I took as well. And there are many areas that need help. And very recently, and I would also like to add that I had no knowledge of how AKS upgrades are done. I paired with Damian and he was really helpful. He kind of held my hand through the process. We hopped on a meeting and yeah, I shared my screen. He guided me what to do. I submitted my first full request for it. And it is not even, I think it was two days back. I am pretty new at this as well. Yeah, Dheeraj, please can we move on to the next? Okay, so these are some steps that I follow and I recommend that any newcomer can follow to get acquainted and start contributing to Jenkins. So first of all, there's listening. So attending meetings some are weekly, some are bi-weekly. I think that is how you get to know. And even it is something from where you can understand, okay, is this something of my interest? Is this something that I can contribute to? Second is learning Jenkins as Mark said before, it is completely Java development and Java was not even my, but it's still not even my primary software development programming language. I'm more of a Python person, but as you can see, I have a GSOC student here. So I do Java. I think willingness to learn is something very important over here. Then comes discussing, one need to be proactive, I guess. You need to ask questions and the Gitter channel during meetings, the mailing list. So discussing would be the next step then pairing. I think everyone is really scared in the beginning when they are making their first comment, first pull request and pairing really helps where someone, some experienced person, maintainer of a plugin actually guides you through the whole process. So that is important. And then I would come to doing, you need to actually take that initiative and write code, not just code actually, generally contribute. So they're doing phase of it. And finally reviewing and being a newcomer, you are again really scared when you are, pressing that submit review button because what if you will say something and it is too rude? What if it is not giving out enough information to the new contributor at the plugin you are maintaining? Yeah, so that thing, and I just made one code review on the project that I am working for Google Summer of Code that is conventional commits plugin. And yeah, I was scared as well, but I was sure that even if I made a mistake there are people having my back and yeah, everything will be fine. So I would like to encourage everyone to follow these steps and contribute. And handing back to Dheeraj. Awesome. So I'm back again. So I'll be sharing my experience of ReactJS and Jenkins. So let's start. So these are the three projects, main projects that have ReactJS technology used in it. So in the next upcoming slides, I'll be going through each project and telling you all about in brief about what the projects are and how you can help us, right? So this is the first project. It's called Custom Distribution Service. So this project was started last year and as a GSOC project only. And I contributed this year in the ReactJS field and I suppressed which all of them got merged. So I had zero knowledge about ReactJS before contributing. I really had zero knowledge and when I got to learn about this project, I was interested to start my open source journey. And this was the project with how I started with Jenkins. So with the help of my contribution, I was able to learn about concepts like component states, React hooks, also SAS and UI designing as well. And there were so many other things as well, like soft skills, like how to talk to people and so many things. And after that, one more thing that I really loved was that I got a opportunity to get my code reviewed by someone who's really experienced. So to be precise, Gavin Morgan was one of them who went through my code and told me that what are the best practices when you're writing the ReactJS code. So that was something I really loved as well. And coming to the areas where we need your help and you can help us are, these are the issues that you can help us with. And these are just some of the issues that we placed on the slide and you can go to the issues link and you'll be able to find all the list. And this is the second project which is called Pipeline Graph View Plugin. So it is a project which is now currently started and just, I want to stress this more that this project is going to be really, really popular because it works on some, as an alternative for Blue Ocean plugin. So any contribution you on this plugin, it will be, right? So, and there's going to be a demo session on this pipeline plugin that will help you all to know more about what this actually is and yes, how this plugin works and what are the requirements of this. So you'll be able to learn more about it on the demo session as well. Now, this is the last project that I want to share with you. So it's called plugin site and I'm sure people who know about Jenkins and have been using it, definitely know about this site because it's very famous and people go through this site in order to learn, search about plugins and try to understand which are the new plugins and recently updated and trending ones and everything. So these are the issues that we have and you can solve and help us with and there are more issues if you click on this link and you'll be added to the page where you can help us. So- Dheeraj, Dheeraj, sorry, I need to pause for just a minute. Oh no, Jyoti's in, okay, sorry. We had an issue that a participant needed to be brought in. Yes, I admitted. So- Got her, thank you. Okay, awesome. So yes, and yes, I was going to share one thing that is this website plugin site is made by Gavin Morgan as well. So he's the same person who helped me during my code reviews. So my point here is that when you're contributing to Jenkins, you get to interact and know and being mentored by someone who are working on some of the most popular projects in Jenkins. So I feel it's a privilege to be at such an environment. So that's my take. And I would really encourage every one of you to test out your knowledge. If you're interested in ReactJS, then you can start with any of these projects and you'll be creating a long impact, I'm sure. You can definitely reach out to the data channels and personally message as well if you like. So yes, back to you, Mark. Thank you. And would you be willing to grant me hosting again so that I could, do you know how to do that? So participants on Mark, wait, do a more and then it will make host. Make host, yes, done. Oh, good, thank you. Thanks very much. All right, I have the controls back. Thank you. And I may have to give you control again later, but let me share my screen and let's look a little bit further then. So how about a pause here to check? Actually, before I share, let's pause to check to see are we meeting your needs? Are there things that you would like to discuss further? Do you want me to go back to the adopt a plugin? Are there specific questions you'd like to address? I'm sorry, Valentin, you're muted. Oh, sorry, I forget it every time. Yeah, sure, I have one more question. The question is, what are the things I have? No, let me start it again. What do I need to start contributing to Jenkins? Obviously, I need a GitHub account. It's obvious. And then you told us we need a Jenkins account. Can you tell us more about it or? Sure can, you bet, absolutely. So let's talk maybe about levels and then you can decide which level matters for you. So the question is, what accounts do I need and why do I need them? So in order to submit a pull request to one of the Jenkins repositories, you'll need a GitHub account. And so that's a good first thing. Be sure you've got to get a GitHub account and you can establish that however works best for you, et cetera, but a GitHub account. Now the question that is, all right, when do I need a Jenkins account and why? And so the Jenkins account controls access to things like the Jenkins artifact repository, repos.jankinci.org. It controls access to the Jenkins bug tracker, issues.jankins.io. So if you wish to become a plug-in maintainer, you'll need an account on Jenkins.io. And the way you get that is you go to accounts.jankins.io and sign up. So if it would help, I can certainly show a demonstration of how what that flow looks like. So, and okay, basically we have two accounts and if I wanna submit a bug issue, where should I supposed to do it? On the GitHub side or in Jenkins JIRA? So like many projects that are as large as Jenkins, the answer is it depends. And it depends on which bug tracker that component has selected. So most components have selected to use the Jenkins issue tracker and therefore they submitted on JIRA. Some have chosen, and this tends to be the more recently created, have chosen to use GitHub issues to track their issues. As an example, the git plug-in tracks its issues in the Jenkins issue tracker. The other plugins that let's say are much newer like the pipeline graph view plug-in that D'Rodge mentioned, that one I'm pretty sure tracks its issues in GitHub. It's a very new thing and the author just didn't wanna bother with creating and managing a separate bug tracker. For him, it was easier to do GitHub issues. And so where do I report an issue? The easy check is look at the GitHub repository. If it doesn't have issues enabled, then you know it has to go to the Jenkins issue tracker. Yeah, okay, sure, thanks. Now another reason, so let's see, I listed two key reasons why you need a Jenkins.io account. One is the issue tracker and the other is the repository, the archive, the artifact repository. It's actually hosted for us by the kind donations of JFrog. It's an artifactory instance and it's an amazing thing that they do. They are wonderful to host it for us because it's huge. So in order to get, in order to publish a release to artifactory, you need to log in to artifactory. So it's not even enough to get the Jenkins.io account. When you adopt a plugin, you'll read the instructions and the instructions will tell you, please log in to repo.Jenkins-ci.org with your Jenkins credentials. So those are the two account, those are the two or three account things that I'm aware of. Did that address your question or are there more questions? Yes, sure, sure. Thanks. It's mostly answers my questions. Great. And Jodi, I just got a request to admit Jodi again. So we'll see, did this work? Okay, good. All right. So... Also, yes. So I was just asking you that if somebody else, like he's working on his, he or she's working on their own, if they have a doubt, they can also reach out to data channel for newcomer contributors, right? That's correct, right. So any of these kinds of questions are very well suited to ask in newcomer contributors. We love to see them because in a perfect world, you ask a question in newcomer contributors and we paste a link to the documentation that tells you what to do. In the imperfect actual world, you ask a question, we realize we don't have the answer to that question. We answer the question and then we put it in the documentation. So in either case, a question to newcomer contributors is deeply valuable because it helps us learn what other answers we need to give. Yes, got it. All right, so was everyone comfortable with where I ended on the adopt a plugin? Do you wanna go back and take some time in that? Would you like to, we're at about an hour, we could take a five or 10 minute break and then come back to identify our next topics. What's your preference? Maybe a break. Yeah. Okay, so I'm going to call for an eight minute break, seven minute break now. We will meet back together again in seven minutes. This way I can take a break away from the keyboard. I can stand up and walk around a little bit and then I'll be back. All right, so in seven minutes, we'll be back. I'm gonna, let's see, and I'm gonna put up a slide or something on a shared screen to show that we'll be, actually, I've got a countdown timer. Thank you. I'll put a visible countdown timer shortly. Okay. Okay, see you, thanks. Thanks everybody. We'll be back in about seven minutes. All right, thanks everybody. So in terms of topics that I think we could address, we could talk about plugin development, what it means to do some of the specific items that we've listed. We could talk about pipeline development. We could talk about, we could go back to the adopting a plugin. I think we're pretty well covered there. We could take topics of your choosing. Are there specific topics you'd like to consider? Sorry, I just missed it. I have a question about plugin development. I'm trying to find, when I'm searching through the Jenkins website and everything else, I keep on running into plugin documentation links that are all set to read-only and like normally three or four years old. So where is the current documentation for plugin development? So I'm assuming I'm just looking the wrong place, but. No, no, you're, it's a broad mix. There is plenty of documentation that is useful even in the read-only Wiki site. However, the best and most authoritative is on Jenkins, on www.jankens.io. Okay. And let me, let's go there. Let me share my screen and we can look at it together. But this may not address your specific question, but let's try. So here I'm gonna go to this. Let's see, do you see my screen with the slides on it? Okay, so let's look at Jenkins.io. And so here is the, let me see that I got it. Okay, size it correctly from my screen. So documentation. And now if we look at the developer guide down here at the second from the bottom, what this gives us is links to various things. All right, the first, how do you get started writing a new plugin? That's actually rather uncommon now with 1800 plugins. Most people don't need to write a new plugin, but if you're interested, we could go through that. Then there are a series of how-to guides that guide us on specific needs and specific challenges. Jonathan, was there a specific? I don't end up, when I'm searching through like doc.go or Google, I don't end up here. I end up. And that's, that I suspect is because many of the questions are answered on the Wiki and hang on just a minute. I've got something. Oh, good, okay. Yeah, so there are plenty of things that are linked to the Jenkins Wiki. And because of the links to the Jenkins Wiki, maybe we could test this one specifically. Is there a certain question that you've got a little more specific? And let's look for it together here. No, well, just, I don't know. I don't want to monopolize things, but like I said, when I was trying to, when I migrated at work, when I migrated the Jenkins instance to the newer LTS, then I tried to bring in that old plugin that I was using, it just, it threw errors. And so then I just opened it up. I had the old source to the plugin and I opened it up and sort of tried to update the palm and then also it was throwing errors all over the place. And then I went to look to try to solve those errors. It was missing some of the groovy parts of it. We're missing some cross-site scripting fixes and a bunch of other stuff. And I just kept on, when I, as I was searching for the issues, I ended up on the Wiki and I was finding sort of old stuff pointing to like NetBeans plugins that are no longer available and pointing to IntelliJ plugins that are like your date and stuff. And so I was just trying to figure out where the kind of, yeah, so. Yeah, well, and you highlight, you highlight there's a broad collection of information on wiki.jankens.io. I think the specific thing, probably the first thing you were doing or would have benefited by doing is this updating your Maven parent palm. Because what that does is that, and if you're willing, we could actually try this live if you'd like, but what there is here is this guides us to, hey, how do I take my older plugin that was probably using this kind of format and get it into this format and adapt to the new Jenkins parent palm. Yeah, I figured that stuff out eventually, so yeah. So I don't, like I said, I don't want to take up unless other people will find this useful. I don't want to sort of monopolize things, but. Okay, yeah, so for me it's worth, I think it's worthwhile highlighting some of the things on this page just for everyone's benefit, because when you adopt a plugin, one of the early things that you'll probably do is exactly this, update your Maven parent palm. And the steps that this provides are necessary preparatory steps for some of the later steps like using the Jenkins Bill of Materials. So by saying, okay, we're going to do updating your Maven parent palm, this change, okay, it looks pretty simple, right? We're going to change the parent from being without specifying a version to instead now specify a version, include the relative path markup and set a separate property for the Jenkins.version. That exercise alone will now update you. And now here you should probably then, most of us should look at that version number and say 1.625 is very, very old. And now there's a little bit of extra guidance. Choosing, let's see, it's, if I look at it this way, here it is, this. So you remember I said, hey, 1.625 is old. There's a page in this set that says choosing a Jenkins version to build against. And Jonathan, one of yours is, you were updating to a Jenkins LTS version and you're probably not going to do anything without old plug-in on an old Jenkins version. So for you updating to a new Jenkins version is probably a good thing. And so this guidance says, okay, it gives us some instructions on how do we choose what Jenkins version we should make as the minimum value for this Jenkins.version. And then it gives you some trade-offs. Okay, if you choose to keep it low, you can increase your adoption. If you go make it much, much more recent, you can use more recent features. You should generally not use something that's older than about a year because things that are older than a year have sort of fallen off the edge of the update center. And so when it says, when this one says 1.625 and you go looking in the history and realize, wow, that was eight or nine years ago, you can clearly make a move to a newer version and you can choose a much more recent version saying, okay, I'm going to choose and now we look what does it recommend. And this page says, okay, choose either 2.263.1 or 2.277.1. And the cool thing for me about this page is it updates automatically based on LTS versions. So it's going to six months from now show us different versions as the recommended base version. So update your parent POM, good first thing. Now you may say, oh, oh, oh, you do that and you get this message. Oh, I'm getting require upper bounds messages and these are the kinds of messages that happen. And guess what, this is a great excuse to then look at, oh, maybe I should switch to use the Jenkins plug-in bill of materials as referenced here because what it will do is solve many of those kind of problems for you. So you don't have to solve them anymore because what this bill of materials concept is, is there's a repository in Jenkins that has a bunch of automated tests that test all sorts of plugins in combination with each other at version numbers and then records those version numbers in this thing and all you do is use the results of other people's testing to decide what version you want to base yourself on for a particular dependency. So now I fear this was such a novel concept for me that it took me a little bit to think about it. Do you have questions about how those dependency version numbers are managed or things like that? No, I have to play with it a bit first. Okay, so this is that, okay, update your, as you choose a Jenkins version, you can update to use the plug-in bill of materials and the plug-in bill of materials will simplify dramatically your management of version numbers of dependencies. Okay. And I cannot praise this nearly enough because in the example of the plugins that I maintain, even some of the low volume plugins, it has been a dramatic improvement in the simplicity of these POM files by being able to use the bill of materials instead of calling out every single version number of every single dependency. Okay, great. I had a question, Mark. Yes, please. So what level of autonomy have the plugins in regard to dependency? For instance, I beg Apache HTTP client. It is very common or is very used across multiple plugins. So if the plugin that I'm using, it depends on that particular library. I can upgrade it just for my plugin or it has an impact on remaining plugins. How? That's a very good question. So I think what you're asking is, what is the downstream impact if my plugin declares that it needs a newer version of one of its dependencies? Is that a fair way to say what you're asking? Yeah, okay. So let's take the specific example of the Git plugin. If it says it needs, it will require at least a certain version of promoted builds. Then what that means is when users install the new version of the Git plugin, if they don't have at least that minimum version of promoted builds, they will have to upgrade to it and Jenkins will offer the upgrade automatically to get that new version. So if I mandate a newer version of dependency, then when someone installs my new release with that mandatory newer version, they must have at least that version installed. They can have a newer version than that, but they must have at least that version. Did that help? Yep. Okay, so for me, that highlights one of the real benefits of the Bill of Materials. Before I implemented Bill of Materials in the Git plugin, for instance, I was terrified to update dependency version numbers because I worried that I was going to break someone. I worried that I was going to force them to upgrade to a newer version of a plugin. And I spent an unjustified amount of time worrying, oh, do I dare increase the dependency version number of let's see, my examples were of the matrix plugin. Will I break someone because they depend on a very old version? Well, with my transition to the Bill of Materials, the decision is no longer in my hands. It's whatever's in the Bill of Materials. And what's happened is that's promoted the decision amongst many, many plugin developers that they will all bias towards depending on recent versions of plugins. So all of a sudden the entire Jenkins community is getting the benefit of more frequent upgrades to plugins and getting more people on largely the same versions because of this Bill of Materials change. So for me, the Bill of Materials has been not just helpful to me as a developer, it's been helpful to the users because they're tending to get more of them on similar version numbers. So did that address the question, Marcel? Yeah, perfect. Super, thank you. Other questions? I maybe can share my experience. Just a short. Yesterday I have reverted my Jenkins installation to the previous LTS version. And about 20 plugins didn't match the version of the previous LTS release. So it wasn't possible to step back one LTS release. Maybe it's, it will help someone. Well, and that's where you're going from 289 back to 277 or 277, okay. So, and that has been a, that has certainly been a big transition. Now, do you track your, do you track or have you attempted to track your configuration with configuration as code? No, it's painful. I really like to use configuration as code, but we deployed Jenkins the old way, not in a container, but installing in the file system as a war file. And all the dependencies lay in the file system in Jenkins home. And there is no way to, you know, just to tell, okay, with this new version come this version of plugin because they are already there. Right, right. And it is an impossible to apply configuration as code in such manner in container world. It is, I think it is easier because you start a new container. There's such a great feature that you can install all needed plugins for this particular Jenkins version inside this container and run it, but not if you install the old way, the file system way. And this is a problem right now for us. So I was living in exactly that kind of a world and I agree with you wholeheartedly. I installed from a war file I was using in my case, the Debian package, right? So I installed the Debian package onto my Debian or my Ubuntu, but I was able to find a path that let me eventually move towards that. And I wonder if it might be worth your considering one of the things that, okay, I don't wanna disturb my production instance, right? It, we're gonna continue managing exactly. But what I found was that if I took a copy of that instance and attempted to build myself a preview of it or a prototype of it in my case, I built it in a Docker image. So I ended up taking with R-Sync a copy of the plugins directory and the config.xml files for the jobs and various other config files and then one little file at a time, one piece at a time, my separate copy got a little bit of configuration as code in one segment and a little bit of configuration as code in another. And I spent months of slow progress getting there, but those months of progress ultimately ended up with, I was able to confidently replace my war-based slash deb file-based installation with one that runs from a Docker image on the same machine because I eventually got them synchronized well enough. So it's, now, if you say, oh, I don't need or want a test environment, then my technique may not help you. But if you're interested in it, I can paste into the chat a link to the thing that I use. So maybe my tooling would give you a little pointer. What we do is exactly what you have described. We use our sync to copy the whole Jenkins home directory to a new virtual machine. And we start a newer version of Jenkins and start the migration on this test machine. And if it's go right, then we make the same thing on the productive machine. But you brought me to the idea we should not copy the whole Jenkins home. Maybe we should make it smaller pieces copy. Not everything but parts of it. At least for me, it was a positive experience to incrementally start from wherever I was, right? With everything managed the way I was used to managing Jenkins with everything done from the user interface. And I had, I clicked through web pages to make every change. But then that our sync and copy those contents into a repository was a great help. It turned out very, very useful to me and it's made my development better. All right, the embarrassing thing here is not just made my Jenkins installation better, but it's made my experience as a developer of Jenkins components better because I can now easily drop my test code into something that looks very, very much like my production environment. Yeah. So if you're interested in the technique, the incremental move towards configuration as code, I'm gonna put this into the chat. See, and now this is truly evolutionary embarrassment publicly displayed, all right? And if you look at the history of this particular repository, you will realize that Markweight hangs his head in shame at some of the mistakes I've made in going through these evolutionary transitions, right? It's, oh, wow, that was foolish. Well, but that works, oh, but that was bad. So you're welcome to that. In my case, the concepts were of incremental improvement were so valuable that my mistakes just didn't matter, right? It turns out that incremental improvement made it so that the end result is better even if I made a bunch of mistakes on the way. Yeah, we learned from our mistakes. Right. Yeah, cool, thank you very much. All right. Surely will help us, Army. Well, and for me, it's a reminder that the other thing that that experience of having a readily available thing that I can stand up that looks really close to production is that it lets me very rapidly get into interactive testing of some change I'm making. So we were just doing a Google Summer of Code project and that Google Summer of Code project made an important change to the Get Client plugin and I needed to test it and it was minutes and I had that thing deployed into this environment that has thousands of jobs and has interesting configurations and is known to have problems in places that most people don't have. So for me, it was, but that's, it's been an investment, right? I mean, doing incremental transition from old to new has taken time. Yeah, sure. All right, so looking to it. Great, we've talked about development and transitions for plugins. Are there other things around plugin transitions? Let's see, Jonathan, for instance, on yours, you mentioned that you've had to upgrade and find your way through how to bring an old plugin to be current and the plugins that are up for adoption commonly have that exact problem. They need to be updated and you've got to explore, okay, can I update it to depend on a modern Jenkins version and what will that do to the code? Okay. Yeah, thank you. Yeah, I think I'm going to use Marcel's idea and take a look at some of the plugins that my instant uses and see if some of those are up for adoption state. And I like that very, very much. That's a great way to be able to have a good conversation the other day with someone who worried, hey, but I can't give 40 hours a week to this kind of thing. And I think that plugin adoption is a place where you could give 30 minutes or an hour a week and do significant work, realizing that if a plugin has been placed for adoption right now, that means there aren't people working on it. So any time you give to it is time that is net benefit. Now, if you'd like, we could look at Jenkins Pipeline. Do any of you have pipeline experience? Have you made the transition to pipeline or is much of what you're doing related to freestyle? My, I'm old fashioned. My stuff is all still freestyle, but. Okay. I have a little combination. I'm using pipeline, but also I'm using the library. So I'm provisioning common functions there through groovy, mostly. And then I make uses of those from my pipeline. So, okay, so you're what I would call even in a relatively advanced thing, you're using pipeline shared libraries so that you can have simple expressions of pipeline in most pipeline files that call something a little more complex in the library behind it. Right, yeah. Also, yeah, since we have everything on top of Kubernetes, we are using configuration as code and all of that. So we, at least that issue in which we have to replace a grade or downgrade, not that we haven't needed to downgrade, but yeah, that's something that you should look at for sure, Valentin. Yeah, that's my easier life. And now in your Kubernetes environment, are you managing things there with Helm files or with YAML directly? What's been your preferred way of, or are you using the Jenkins operator? Which, what's been your preferred way of deploying all the way to Kubernetes? No, so when I started to implement this on Kubernetes, I thought that the Kubernetes, the Jenkins operator, it was much sure enough. So I went to Helchar. At that time, it was hosted on the Kubernetes repo, but now it is as we know on the Jenkins IO Helchar. And that's my easier things as well, because it is just matter of changing a YAML file, a value, sorry, a value on the Helchar and then the whole thing roll over pretty easy. Yeah, Helm, it sounds more better approach than just using crawl YAML file. So now in your roll forward and roll back experience, have you found that there were unexpected barriers or things that you could share with us to say, hey, it would be better if we did this or our experience would have been better had this been in place instead? So one of the things that I have been thinking is that I need to improve the way that I'm rolling out new grades, because I have found in the past that I am just grading the LTE version on the Helchar value. And then there is a dependency of that on plugins, specific versions. And then since I fail on read the migration process, my grade fails. So yeah, I have been thinking of having like a test environment just to see how the grade goes. And then if everything works fine, I could be moving that to grade to production. And I've heard a number of people who use that kind of a staging technique that you're describing, who evaluate something in staging. I think it aligns with the way Valentin was describing they're doing theirs. Your Kubernetes technique doesn't use our sink as I assume going from code. Now in your image definition, one of the things that we learned, I guess it was six or nine months ago, was that many users are making the suboptimal choice of declaring their plugin versions in the definition of their thing, but not installing the plugin versions. So when their new Jenkins installation starts, they were downloading the plugins at startup time. And that's both expensive and slow to process and a risk to you because then if the Jenkins update site is down, your Jenkins is stopped waiting for it to upgrade. Do you know, are you using a separate Docker image to define your Jenkins with plugins or you're defining them? Okay, so you've got- That's another process that I need to improve. So yeah, I guess that the recommended way, I think that I read on the Wiki or somewhere else that I should build my own Docker image with the plugins that I need. Yeah, in terms of provision in time, it will reduce the provision in time. I found that that's a little risky. Just to install on the fly, even though if you are not upgrading, if the pod just gets killed, you will be getting install all those plugins again. Oh, right, I had not even thought of that. The reality is on a pod restart, you get a reinstall of those plugin versions and that's expensive because during a pod restart, you want that thing back as quickly as you can. Yeah, although I should mention that the start, the bootstrap process, I will say that it doesn't take more than five minutes to be honest, but yeah, there are occasions in which a plugin could fail on that because I don't know the instead of using a specific version that was long time ago, a specific version I used the latest version of the plugin declared on the configuration as code. And then what happened is the controller was restarted and on the bootstrap process, the plugin was installed with a different version because I have instead of a fixed version, I have the latest. Right, right, so now you got an implicit upgrade even though you hadn't expected to get an upgrade at that moment. Yeah, yeah. So yeah, having the Docker image with all the plugins that's for sure one of the things that I want to do for the reason that we have that. May I ask a question? So if you have a new image with newest plugins, for example, six weeks past and there is a new Jenkins LTS version available, you built a new image with newest plugins and you want to bring it into your production or test environment, what you do is you have a volume somewhere on the file system bind to your image. And there is plugin information, there is for older versions of these plugins. Are you deleting this directory or how you approach this update scenario? So currently I am not doing anything in regard to the volume. Usually I believe that mostly it is being taken care by Jenkins itself, but what I've realized is that in some occasion when you grade the Jenkins, you can get a warning like saying, you have a null or legacy configuration related to those plugins. Do you want to keep it or delete it? That's why I believe Jenkins is taking care of those. So you don't need to clean up. I guess that Mar you have more information about that. But yeah, that's what I have seen. I have an experience. Any issue related to the configuration? Yeah, there's one more problem with it. If you deleted a plugin from plugin TXT and built a new image and you start Jenkins with this new image and bound volume, you still have the old plugin installed in your Jenkins environment. And you cannot get rid of it because it is in your file system that's bound to your image. Well, and so that was why, at least from my usage, I've preferred to have the Jenkins, the base Docker image includes the plugins in the image and it's not a separate volume, right? It's absolutely just part of it because what I wanted was I want the ability to know that the thing I described I could go back in time if I had to and build it again. Now, this for me is actually a relatively recent thing because I spent the longest time doing exactly what Marcel was doing of using latest. I always want the latest plugins and so I wanna stay with latest. It turns out that this new tool called the plugin installation manager has some automation inside of it that will help me maintain the list of, okay, I was lazy. I didn't wanna maintain the list of exact plugin version numbers manually. That was just, I've got 150 plugins and tracking those version numbers was just unacceptable. I couldn't imagine tracking those numbers but the plugin installation manager tool is this Java program that will generate the exact list of plugin name version pairs and write it to the file for me. And so what I've got is this ability to say run one command that says, tell me the current version numbers, write it to a plugins.txt file as exact version numbers and another command that says, now go download exactly those versions from the update center. So I was using the exact technique Marcel's described of latest for the longest time for years and it worked just fine but it meant just the way Marcel described it, sometimes I would get silent upgrades of my plugins and I hadn't thought about that and didn't know how to go back if I wanted to go back. So, but for me, the magic there was the plugin installation manager tool and I found the set of arguments to pass to that thing to use it so that it would maintain the file for me because otherwise I would never have tolerated maintaining all those version numbers. I'd have never kept up to date. Yeah, it's almost impossible with 150 plugins. Now there is a different technique and there's a different technique that the Jenkins infrastructure team uses. The Jenkins infrastructure team uses a dependabot configuration that will watch the Jenkins update center and propose pull requests to their plugins.txt file for new versions. And so they're still tracking exact version numbers but if you're interested in that I could probably paste you a link to that one if you say, oh, I wanna use dependabot to track these things. That was an interesting technique that the infra team found. If I understand this correctly, dependabot works only with GitHub. That's correct, yeah. So if you're using, if you're locally hosting or using GitHub or using BitBucket, then it won't help. Okay, PT for us. Well, but that's where the plugin installation manager tool will work for you. And work just fine. Maybe you can post a link about plugin installation tool. You bet. Okay, cool. Yeah, so let me. Only tool I know is the Jenkins CLI jar. Sorry, go ahead, Marcelle. What was that? I would be interesting to see how the infra team is using dependabot for that. Yeah, that's very interesting. Super. And to be honest, I am struggling with what you just mentioned. I need to go over every plugin version when I am grading. I think that there was a major grade on the LTE's version some months ago. So I went through all of those. And also, especially because I grade it from JDK 8 to 11. That was another milestone on that LTE, yes, I believe. But yeah, I have to track all the individual version for plugins. OK, so you're headed in that direction. You see that coming. Yeah. OK, well, so let me. I'm going to paste a link to this thing that I use to get available updates. And yes, so here we go. So in the chat session, whoops, where did I put it? Here is the Python code. OK, so I'm a Python scripter. So Python script that calls the plugin installation manager tool to maintain the precise plugins.txt file. So there's that one. And then let me get the Jenkins info reference because I get those pull requests all the time upgrading LTS plugins. Upgrade LTS. Maybe it's called plugin upgrade. Sorry, I'm having to look. I have to look in trash. I may have thrown them away just a minute. Maybe the word is update. English is too fluid. It allows too many synonyms. OK, I will have to take a separate action item. I'm not finding it in my search. And I know I get them all the time. Plug in update Jenkins. Infra plugin update. I am so sorry. I'm not finding it. I know that I get this message all the time. And so I will I will let me take an action item to gather that. And if you're willing to actually let me paste my email address, if you're willing to send send your email address to mark dot Earl dot wait at gmail.com. And I'll share the link to the Jenkins info repo. There we go. And I am feeling awkward now because I should be able to just find it. Let me look for it with a slightly different technique. It always happens when you're trying to do a demo. Right. That's that's the price I pay. So I think it may have the word Docker in it. Ah, yes, there it is. OK, good. I found it. OK, so if we look at this one with Docker, yes, I found it. Oh, I'm so proud. OK, good. See the Jenkins infra LTS upgrade process at this thing. And I'm going to go ahead and share my screen and let's take a look at it just so you can get a sense of how it operates. So here is the you should see the Docker Jenkins LTS repository. Now, do you see that? I do. I do. And in the .github directory, here is. So in the .github directory, we have three workflows enabled. So dependabot is here that runs GitHub actions. And then in the workflows, we've got update.yaml, which does this operation. Let's see. So it generates the token. And then it runs on the Update Plugins branch this operation here. Oh, no, here it is. It's this one. It's this Jenkins infra UC. This tool is a thing that looks at plugin lists and generates an update to them. And the result is written as one of these pull requests. So here it says chore dependencies, update plugins. And what happened is it's proposing a change from warnings in G9.2.0 to 9.2.1 and from workflow CPS Global Live 2.20 to 2.21. And a human being didn't have to do it. It just did this on its own. This is gold for my eyes. Great. Great. That's excellent. Thank you so much. Well, and for me, it was this is work that Gareth Evans did as part of Jenkins infrastructure. And it's been absolutely wonderful for us. It helps us maintain things better and keeps us up to date. Mark, one more question. Does it update each plugin to the latest version or some particular version? So the thing it's proposing is it proposes the most recent version. But it's a little more sophisticated than that because it's proposing the most recent version that is supported with that Jenkins version. So for example, it is perfectly legal for a Jenkins plug-in to declare that it requires as its minimum version Jenkins 2.299. And when I try to install that from the latest LTS, which is 2.89, it will correctly say, no, you can't have that because it's too new. It requires a much newer Jenkins version. And this tool will not offer that update because it's not supported with the Jenkins version that is trying to match. OK. Yeah. So very good question. Very, very good. So there's Intel behind. There is. And that same intelligence exists in that plug-in installation manager tool that I was describing earlier. It does the same thing. In order to help, in order for it to make a recommendation, you must tell it which Jenkins version you're targeting. And it will then use that information to provide the list for you. Cool, very cool. In your case, Valentin, if you are not using GitHub, you should be able to look at the implementation of the GitHub action that Mar share. Yes. This is implemented in using Docker. OK. It's a Go application, actually. So you should be able to use this implementation on your site as well, regardless you are using GitHub or not. OK. OK, I will be looking into it. Well, and Marcel makes a very good point that most of these things are done exactly that way, right? Where this, let me share that screen again just to show, because it's good to. So if we look at this update plug-ins pull request and we go look at the repository in the .github workflows, there's this entry that says Jenkins Infra slash UC. Well, guess what? That, as Marcel correctly noted, is just a Docker image. This is an image. And if you say, oh, well, where is that coming from? Well, guess what? It comes from a repository in Jenkins Infra called UC. Yeah. This is what Marcel posted into the chat. Oh, very good. OK, great. Yes, so there it is. And this, yes, perfect. Thank you. Oh, yes, there it is. Thank you very much. Thank you, Marcel. Cool. Yeah, that's how I learn things. It's an occasion I look at the GitHub actions that people are using. Not that I'm using GitHub actions. We use Jenkins, right? But yeah, it's an occasion I learn how people are doing certain things. And if it's not, yeah, if it doesn't fit on my infrastructure, I just adapt it. Excellent. Very, very good. Thank you. Thank you very much. Yeah, thank you. Are there other topics that we would like to touch on, or other things that come to mind as a question? I think I'd like to add something. So yes, so as a newcomer contributors, some of people would not know that how to go and check out all the available GitHub channels that Jenkins has. So I think if I paste the link for Jenkins ci.slash.com on the chat, so people can look at it for obviously those who are present in the meeting right now. So they can look at it and join the available GitHub channels that they like to be. That's excellent. Let me I'm going to go ahead and share the screen so we get a screenshot of it. So what this shows us is, or Dheeraj, maybe you can describe what we're seeing here. Exactly. So these are the GitHub chat channels, right, that are available to Jenkins users. So if you've got a question about configuration as code, there's the channel. If you've got a question about, let's see, what's a, oh, we've got lots more to go through. Let's look for the plug-in installation manager tool. Yep, there it is. Or maybe you've got questions about the Jenkins Git plug-in. Here's a group that focuses on that. And it looks like there are many, many, many chat channels all focused on different parts of using Jenkins. Thanks, Dheeraj. Good suggestion if my stop share goes there we are. So I'd like to share one very small experience that I think might help someone who's in the same position at me that has been new to contributing. So when I was learning about configuration as a code plug-in, I was very, I still am very interested in it because it works like a magic to me because so it's really cool. So I came across one technique that in order to configure the plug-ins using Jcast plug-in, we need to know it's YAML syntax. So everyone does not know how to write the correct YAML syntax for configuring a particular plug-in. So what they can do is go to their own Jenkins instance and configure it and come back to the YAML file and then copy paste the code. So I know it would not make sense to someone who's new to this. I'm trying to guess that one on Dheeraj and I know that someone who sent me and I assume that people would know this very easily. So the point I'm trying to make here is that there's always something that you can contribute from your end and if it's not going to help everyone, it's going to help someone for sure. So you need to volunteer and bring the idea to the Gitter channel and we can discuss more on that and we can put it and publish it if it helps anyone. So welcome for the contribution from that day as well. Excellent. And Dheeraj, you did a great blog post actually and a video on that configuration as code experience, right? And that blog post and that video were good highlights that, hey, the experience can be much simpler, much easier if you use these techniques. Exactly. And I will boast myself by saying it has more than 400 views now. Congratulations, that's great. So your video is being seen. That's very good. Excellent. Yes. It feels good to know that people are finding it helpful. Now, I believe several of you had noted that you're on the way to pipeline. You've got a mix of freestyle jobs and pipeline jobs. If you're okay with it, I'd be happy to do a brief demo on some things that I think you ought to be aware of as pipeline capabilities so that you don't miss these capabilities as you're considering, should I try pipeline? Would you be okay watching a little demo, letting me go through and talk about pipeline a little bit and trying to sort of introduce the concepts and then show some demonstration of what you can do with pipeline and what many people may miss as capabilities that are available in pipeline that they didn't realize were there. Yeah. That'd be good. Okay, cool. So, Marcel, any question from you or concern there? Yeah, I have to go now. Sorry that I have another meeting, but I would like to ask, I believe someone mentioned, you're gonna be a demo on this pipeline graph view plugin? Later today? Yes, I think that's later today during the, I believe the pipeline graph view plugin will be shown during the, oh dear, what's the title? During the Ignite Talks and Demos. Okay. That's an entry on the agenda, right? It is, although if you would just like, yes, it is an entry on the agenda. It's scheduled to start in about, let's see, we're at 10.30 now, so eight, nine, 10, 10.30. So it's scheduled to start in about 90 minutes, but Marcel, I can also paste a link to you for you of an existing demonstration of pipeline graph view that we had a video of. That way you could even look at the video separately if for some reason you couldn't come back to attend the Ignite demo. Okay, yeah. Let me see if I can find that really quickly here because that should be pretty easy for me to find as a video. I posted it to colleagues inside my company some year, some time ago, pipeline graph view. Am I, Dheeraj, am I getting the name right? Is it, it is pipeline graph view plugin, right? Yes, there you go. Pipeline graph view, yep. Right, okay, and now where is the video of it? Pipeline graph view for, pipeline is, okay. So I've got to look for it a slightly different way. YouTube.com, Jenkins playlist, because what it was was we had the author of the plugin presented it in a brief demonstration in a, presented it in a brief demonstration. I'm getting feedback. Is anybody else getting feedback? Yeah. All right, so we'll continue. Yeah, sorry about that. I don't mean to be echoing. Okay, so let me see if I can find that just really quickly because it should be in the playlist. Yeah, we are using it. I intended to ask questions about some limitation. Yeah, some limitation. We just implemented a new pipeline and we found that the parallel execution of several states, they don't show properly. Even though on the classic view, it is presented properly. Okay, so maybe this is a limitation or something. So I intended to ask. Perfect, if you're already a user of it then this video I was going to link you to is no help. So about 90 minutes from now, join the ignite session and we will look for the demo there and you can ask your question there. Perfect, thank you so much. Thanks, Marcel. Thanks very much for joining us. Have a great day. Thank you. So I was gonna go ahead and show some things relative to pipeline. Let's first give a brief, I guess a simplest way to say it is a brief look at some of the concepts around pipeline. And let me see if I can find my slide deck to share. Not that one. Too many tabs. Ah, yes, here we go. Okay, so this was just a very beginning kind of thing. So the idea here is that Jenkins, whoops, copy the link in case you want the slides. There's a copy of them. These are no way polished enough to be claimed to be perfect, but they're a beginning. So you're familiar, well, present with pipeline with freestyle jobs. We configure them for the web browser. It's really easy to do. We store them inside Jenkins, makes them easy to change, but it's not nearly as easy to see what's changed or why it was changed. And we don't get a lot of help from people. They just made a change and they went on and it's strongly dependent on plugins. And if a job starts, if Jenkins stops, the freestyle job stops as well. There's no way of continuing it to run across a Jenkins restart. Jenkins pipeline jobs are configured from a source repo. So you configure them as code. They're right inside your source repo so the job definition is not embedded in Jenkins. Storing it in your source repo makes it easier to maintain, easier to see what's changed and gives you get comments from the people who made the changes. So it's using a pattern you're accustomed to and it puts the burden of the work predominantly in your build scripts instead of requiring that you find a wide set of Jenkins plugins. So they're also able to continue running across a Jenkins restart. They're able to run in parallel. They're able to run on multiple agents and they're able to run with multiple software configuration management systems in various interesting combinations. Very, very flexible and very capable. So there are two domain specific languages that are implemented in pipeline. One is declarative and the other is scripted. Declareative is the second generation of pipeline language, if you will. It's intentionally simplified, intentionally designed to be managed and read and implemented by people who may not be precise programmers. Scripted looks an awful lot like Groovy code. It's a DSL that's derived from Groovy. It is more difficult to read but it's got a larger feature set. And now for me, the cool thing about this is that these domain specific languages are dynamic. The keywords that are used in the languages, the steps or the tasks are defined by the set of plugins that you have installed. And that means the pipeline snippet generator and the directive generator can let you use exactly what's in your system. Now it's time to stop the slides and let's get to a real demo because this is where I think it matters the most. So let's look at my Jenkins installation. Oops, wrong one. My Jenkins installation here. Okay, this is a real Jenkins installation. It's Jenkins 2.289 pre-release. It's got 30 or 40 agents connected to it. Some of them are dynamic from the cloud. Others are here and there and everywhere. So a real Jenkins. When I want to define a new plug, a new job and I want to put pipeline into that repository, I just click open blue ocean and click new pipeline. And now it asks me, which, where do I keep my code? And okay, Bitbucket, Bitbucket server, GitHub Enterprise, GitHub or just Vanilla Git. And in my case, let's see, do you have a preference? I think I've got accounts on most of these. I don't have a GitHub Enterprise account, but the others we could, you want to use Git, would you like to use GitHub? So, Valentin, let me ask you, which repository management system are you using? I'm using Bitbucket. Okay, good. So let's use Bitbucket cloud. Okay, now I've got to get some, a username and password. So for this, I'm going to go to Bitbucket cloud. Let's see, and so Git, Bitbucket, and I may have to turn off screen sharing briefly if it prompts me to enter a password. Let's try continue with, oh yeah, let's try this just to see if it's connected to my Atlassian account. That way I didn't, okay, now I have to insert my security token. Oh, I'm so proud of these things because I've got two factor off. Yes, okay, good. Here we go. All right, so now let's look at various repositories. So here's a repository. Now this one already has a Jenkins file in it. So it's already defined. We can just use that one and let's try that. Or if we would like, I could create a new repository that doesn't have, let's see, maybe we should, well, let's take that one. So I need to get a username and for this, I need to copy my password. Okay, now I'm going to temporarily suspend sharing in case it were to publish this password visibly. So just a minute, stop share. Okay, and I think I'm marked up URL.wait. Okay, and it did not show my password in plain text so I can start sharing again. We've got a new visitor, Abhishek. Thanks Abhishek for joining us. So now I'm going to share my screen again and let's look at, okay, so here, let's try this connect. We'll see if I got the right password, et cetera. Connect, hmm, I'm not seeing what I wanted there. I wonder if maybe I gave it a bad password. Let's check my account here because it may be, Valentin, do you remember, does Bitbucket require that I use something other than my email address? Maybe I should check my profile, huh? I'm not sure. I think username and password is the thing that you need. Yeah, so, okay, so let's see what I've got as my username. We're going to try a different username and if this doesn't work, we'll try, we'll switch to use GitHub. Okay, so there it says invalid username or password. At least the feedback. Yes, exactly. So we're going to switch. I'm going to use GitHub for this one just for the moment. It's okay, yeah. This one, I know it already has my credentials in it. So here, if I use GitHub and say marky wait, now it lets me choose one of the repositories. And so for instance, I could choose the repository named bin or I could choose some other one. Let's see how about, let's go looking. Let's take bin for now, bin and create pipeline and it's going to tell me on this one, oh, I've already got a pipeline. I'm going to start using it. But then we're going to use this exact same set of tools to edit that pipeline and make some changes to it. So it found not just my master branch but also two other branches and ran work on those two other branches. And here, one of them's already finished. The other one's finished and there we see it. This is all just part of Blue Ocean. And pipeline graph view, the one that Marcel was referencing gives a similar view to this with a much lighter weight, still very, very new environment. So here we've got this. Notice in the top right-hand corner, there's this little pencil icon. So I can click that pencil icon and it puts me into an editor that lets me edit my pipeline. So here is the build step that I defined and it has a message that says building and I'm going to say building the master branch because I'm on the master branch, I'm going to save and now I'm going to go back here. In the test, it says print the message testing. I'm going to say the master branch and it adds a warning badge. And then I've got a deploy step where it says, oh, let's save the artifacts. All that I can do from this Jenkins Blue Ocean interface, it's that simple. If I said, oh, I want to go parallel, okay. I need a second test. And here we are going to add a step that is print the message second test step in parallel. So there's test and maybe we should rename this one instead of test, let's call it first test. All of this directly from the Blue Ocean interface. So here I am defining my build pipeline in a graphical experience that lets me just add things where I need to make comments, et cetera. Now I'm going to save it. And in this case, add a parallel test. Change the messages. And I could commit it to a new branch or I could submit it right to master. Either is fine. You have a preference, which would you like? Master branch or a new branch? Master branch. Okay, a master branch it is. We're going to save it and run it. So now what we will see now is that if I look at the master branch, you look, there's a run number one. And now as I go, oh, there it is. Build number two has started. If I look at number one, you see it's a linear flow, build, test, deploy. Now if I go back to bin two, there's my build, first test, second test and deploy. Now ultimately, most users may not even actually look at these views, right? They may say, look, all I want to know is that the thing finished and published a result somewhere. I don't care about the pretty view, but for me, I find it helpful to do my initial layout of what steps should be in my pipeline from this user interface so that I don't have to worry about exact placement of braces, exact where does everything go? This gives me, now, and if we look at my repository here, we'll see this as code. So let's look at, on my GitHub account, we're going to look at the bin repository. So let's grab one of these and we'll just rewrite it. And here are my commits. Add a parallel test, change the messages. And there it did all this changing for me without requiring that I go into a text editor and do it. So it feels as smooth and easy as a Jenkins freestyle job, and yet it's represented as code inside my repository. Cool. I have a question. Yes, go ahead. The question is, is it possible to run this configuration without pushing your changes to the Git server? Oh, that's a very good question. And the answer is yes. It's, okay, so now that's, I would call that almost an advanced topic, but I'm going to go ahead and show it to you if that's okay. So let's use, you say, well, what if I, what if I want to just experiment with something and not commit to the repository? Here's this replay facility that shows me, hey, here's step number two. And I realized I shouldn't call it master branch because when I'm on a pull request, it won't be correct. So building, testing, second test, let's see, first test, yeah, so, and then deploying, yeah, there we go. So I have changed it, I'm going to say run. Now what we'll see is it's going to do the checkout. It'll, okay, these, I have to admit the steps are all very, very fast, right? Because all they are saying messages. But now if I go open blue ocean and look at that thing, let's look at the message here, building. It didn't say building, so my change was there and yet I never deployed it to the repository. So this replay button gives me the ability to do dynamic tweaks, to do rapid explorations. Okay, but you make these tweaks in a text editor and not in the blue ocean interface anymore. That's correct. I think so, and I've never tried to do a replay in blue ocean, but I don't think I can. So let me double check that because if I go back here, let's look at number two, and there is a, see this rerun button, but when I click the rerun here in the top right hand corner, my recollection is all that does is rerun the job exactly as it was defined. So I'll look at three and here's three, and if we, and now guess what? Four will be available very soon and there is four and four uses two, all right? So I rerun four and it, or rerun two and it did it as a new job, a new version, a new number four. So yeah, there is in a way in blue ocean to do that interactive rework and not save to the repository. Okay, cool, it's new for me. Now, there's another really what I think of as, okay, this is, so you remember we were here in replay, see this link at the bottom, this thing called pipeline syntax? That is magical. I'm gonna click that and we're gonna look to see just how magical that is. So in the pipeline syntax link, it opens up a snippet generator where I decide which step I wanna try. Oh, I need to run a Windows batch command. And I would like that to say echo hello world. And then I want it because it's Windows, I want it to say dir slash od and by advanced settings, I would like the output to come back as UTF-8. And I wanna know the return value of this thing. So I want the exit status, oops, UTF-8. And I want the return status. So I just with the user interface described what I want to do, right? Interactive clicking to describe what I want to do. I click this generate pipeline script and there it is. Now I can copy this. I can go back over here to replay and now I have to do some additional things because I gotta be sure that I run on Windows. And now I'm going to insert in there that thing that I just did. So I have just taken code that it generated for me, pasted it into my script and now I'm gonna run it. And now let's watch it to see what happens. Let's see if I'm any good at writing Windows batch commands. So special thanks to my daughter who donated her computer to let me use it as an agent after it got old. Now you can tell that it's old because notice how long it's taking to clone this relatively small 60 megabyte repository. But this pipeline syntax generator lets me choose what I want to do and then it will generate the code for me. And now that one that I just did was actually relatively simple, right? Oh, okay, it's not hard to write a batch file. When you're doing a checkout and using all of the options of the Git plugin, it's really painful if you don't use the snippet generator. So we're definitely going to use it for this one. Let's, oh, we'll go after a public repository. We don't actually need to authenticate. So now there may be additional settings that I want to add like, oh, I need the advanced clone behavior to not fetch tags and to honor the initial ref spec. And I wanna time out in three minutes if it doesn't finish on time. And I need to use a checkout to a specific local branch. I'm gonna name that branch master. All sorts of things like that. And I could keep adding those. And guess what? When I generate the pipeline script, there is all the magic that I needed to do that job. So now if we go back here, we should see, ah, notice. Here's that, you remember I gave it echo hello world and durr slash od, there it is. So, so pipeline snippet generator is a great way to make your life simpler. It just is. The same thing exists for declarative directives as well. This one where we say, I need to in declarative decide, I only want to run on specifically labeled agents like one with the label windows. Generate that and there it is. And now I could have pasted this into that same replay. Any questions so far? So you have been very tolerant of almost three hours of this. Thank you very, very much. I would like to be able to attend the next session. And I believe it's scheduled to start in about five minutes because I want to talk about Java 11 with others. Any questions you've got in the last five minutes before we end? Hello, Mark. This is Sudesh over here once again. Yes, Sudesh. Hi, in this, in the pipeline script, can you please help me know if there is a requirement for a restart? How can I implement that restart from a particular stage? So you want to do a programmatic restart from stage? Yes, that's right. So let's consider you have a build stage and the test stage, right? So in the build stage, like if let's consider that the build stage is successful and the test, there is some failure in the test phase. So how can I ensure that in my next run, I don't build it once again, but I resume from the test. So that's a good question. Unfortunately, I'm not sure, Sudesh, that I know the answer because I'm used to using restart from stage at this level. And then now, if I remember correctly, we may have to ask Darren Pope or some other friends with more pipeline experience. I suspect what you need to do is in preceding stages, you need to stash the results of that stage so that you can un-stash it, stash or archive the results of that stage so that you can un-stash it in the later stage. So let's try that, shall we? Should we do a little experiment? Thanks, Mark, yeah. So I'm gonna do a run of, oops, there we go. So with this number six, it's saying we restart from stage and it's still doing the get fetch. So I'm not sure how to guarantee you that the restart from stage does not perform the work. Oh, here it is. Actually, there we see it. Okay, it's showing it. It skipped the build stage and assumed it could run right into test. So restart from stage did do what we expect here. Let's look at it in blue ocean to see. Yes, okay, good. So it did do the skip. So the crucial thing for you Sudesh then is that what that means is you must assure that the build stage has archived its results either through a repository archive like to an artifact or a nexus or through a stash if the results are relatively small and then that you in the test phase un-stash. And that's important also because it's possible for a build stage to run on one agent and this parallel test thing to run on two different agents. And if you have a dependency on the build results in the test, which most of us do you want to have saved it in the build and then unstashed it or restored it in the test. So here, let's try that and let's use our techniques here. So we're going to add a step, which is a stash. Let's see, and is it called stash? Yes, stash some files to be used later in the build. And the file we're gonna stash is readme.md. Although that one's already, no, what we need, we need to do something that's visibly not there. So how about we would in this we're going to create a file and we're going to do that with a shell script. S-C-P, readme.md to readme-new.md, okay? And get clean, before we do that we're gonna do a get clean minus X FFD. So we get rid of anything that might have already been there. So this file is the one we're going to stash. So we add a step to stash and we're gonna stash that file. Now in the test stage, we need to do an un-stash. Oops, maybe they call it restore. Yes, restore files previously stashed. And we need to do that in second test phase as well. And I apologize, Sidesh, we're going to run out of time. I'm gonna have to, but let's just do this for fun. I think we should be able to see it and let's watch it. So just to assure that this, there we go. So we've got a stash and un-stash and a restore and a restore. So save that, stash a file in build un-stash in test. Okay, and this will very shortly launch. So there's six branches. Oh yes, master is building. So there it restored the file and here it restored the file. So did that address your questions, Sidesh? Yes, thanks Mark, that was exactly what I was looking for. Thank you. All right, thank you very much to all of you. Thank you for being part of the Jenkins contributor summit today. I'm gonna drop off and the session recording will make sure it gets uploaded so that it's available. Thank you very much. This was... Yeah, thank you very much. Thank you everyone. Thank you for joining Dheeraj. Thank you and have a good night's sleep. Thank you everyone. Aditya likewise, it's midnight your time or worse. You're both heroic. Thank you so much. Thank you very much. Bye everybody. Bye. Bye bye. Thank you. Take care, bye.