 Welcome, welcome, welcome everybody to the Jenkins pipeline authoring SIG meetup for Friday, June 12th. My name is Markey. I am one of the SIG leads. Welcome everybody. We do have a code of conduct and that essentially amounts to be nice. Don't make anybody have to kick you out. With that, I am I put a note. I put a chat in the zoom as well as in the channel to give everybody the docs link to the docs and oh no I can't share my screen. Zoom you fail me you fail me. Give me a second. I'll see if I can try something else. Beautiful. Thank you zoom. Give me a second find out where I'm at here. Can everybody see my screen. Give me a thumbs up if you can awesome awesome. Okay, so we will go ahead and start off the meeting talking about the first item. And that is the pipeline authoring SIG roadmap. If everybody saw the email that was sent out by Oleg. Essentially what we need to do is these current state of our roadmap that we came we couple weeks ago months ago we came up with the items. And I linked a few tickets. These tickets are not very informative they need to be better a they need to be better drafted to support what the item is that's up for the roadmap. Or in some instances items that have been referenced are items which don't really fit or it's like a bug. So we need to go through and change that. Now I've done a little bit, but there's still a lot, a lot more to do. What I want to know is, is anybody willing to work with me to do that. Essentially what we need to do I'm going to use this as a first example. We need to look at each area of the roadmap and make sure that the associated ticket associated Jerry story is actually correct. Does it have enough information to start and, and what not. Oh, like, did I cover that correctly. Well, one thing I would like to add is that it's not really necessary to link Jira. Actually, I would say that the majority of other roadmap items, either link project pages. Or jabs. So you can get a is a kind of quick win. If you have a well defined the Jira. But my personal recommendation would be to document key projects and key initiatives right on the special interest group page, or maybe elsewhere. So that you have more freedom, because editing Jira has its own limitations. And the same time, you just get discoverable on the Jira page. But, for example, if somebody looks for pipeline ordering sick, you will be still difficult for those people to discover the roadmap items. I'm currently working on improving the roadmap rendering. And if somebody wants, I can show how it looks like at the moment. But right now, it's a bit difficult to search roadmap by sick. Okay. Does anybody want to sync with me. Maybe at some point today I'm kind of booked to dealing with another issue with log updates. Does anybody want to sync with me maybe next week to get this done like we could. I'm sure we could probably get this done in an hour or at least get the skeleton up. And I could take the rest what I don't want to do is have to do it all. Yeah, I can work with you. Awesome. Thank you. Yeah, I did my best effort. I was not participating in all platforms of meetings. But yeah, I watched the videos last week. I was still unable to identify what's the purpose of some stories, for example, functional testing tools, or unit testing tools. So, just for the context of sick members. Yeah, there are already some functional and unit testing tools for pipeline. The tools obviously have their own advantages and disadvantages, but for example, for me, I was unable to understand what's the goal with the scope what is missing from the standpoint of sick members. So, for me, it's not just right in the description, but also trying to define the goals for this project and compare it with existing solutions. If there is an existing solution, maybe if it's not well known, maybe it would be rather beneficial to document that as a roadmap item. Then creating new tool. If you really need a new tool, we need to understand what's the purpose of that and what weaknesses of the existing tools it's going to address. Because otherwise, for maintenance of existing tools, it might come along as not invented here syndrome. At the same time, for users, they won't be able to discover the existing tools. So, for me, it's a major concern and that's why I propose to the fix roadmap items or to remove them. Yeah. Okay, we can. I can commit to working with Steven to have this completed by next meeting time. My preference would be completed by next Wednesday. I mean, September, sorry, June 17, because so this is a time of our next roadmap meeting. I think it's reasonable to me to just remove them from the roadmap for now until we flesh them out. Yeah, I think it's something where like, maybe we just at our next authoring meeting, we spend the whole meeting really diving into one specific item and work on it there. I'm going to, based on that timeline Oleg of meeting it completed by Wednesday, I'm going to, I'm going to agree with Devin that was you, right? Yeah, I'm going to agree that we should remove it. Yeah, for the record, I don't set Wednesday as a hard requirement. But yeah, at the same time, yeah, I'm doing some efforts to clean up the roadmap now. And I would really appreciate if some progress is done by Wednesday. If it's not possible, okay, we can postpone it or just comment out the existing items without really deleting them from YAML file. But yeah, if sick members have some bandwidth, I would appreciate if we do something about it by Wednesday. Okay. So we'll get those removed. I'll have that done for four Wednesday. Yeah, so it's better to postpone it a bit because I mean removing because there is a stage to pull request to roadmap, which is waiting for review. And if you remove it right away, there will be a massive match conflict. So, we can postpone removal or commenting it out until Tuesday. No, wait, what are you, what are you needing? You want me to comment it out or remove it? It sounds like you're saying you want me to comment it out. Well, whatever works, because well, that is a good history. So personally, I don't have strong opinion that you're moving and commenting without basically has the same result. Okay, I'll remove them. I think it'll be easier that way when we come put them back in when they're better to find work sort of work. We're starting from a clean slate. I think you're referring to the pull request that will add the preview column, right? Or is that not the pull request you're referencing? Yeah, this pull request, but it's a bit more than preview. So if you want, I can just show it because I have developed a question of the site right now. Yeah, I think it would be a real help because I love what you've done with the preview column. I think it's a great addition. Okay. So do you see my screen? Yes. So this is a developer version of the roadmap. So, and there is a pull request for that. Just a second. It's here. So I forgot to rename the title but actually does three things now. Preview column support, regrouping items, and also adding labels and filtering them. So what I've done, now metadata includes some additional fields which we can use. So for example, yeah, there is labels again with definitions right inside so everybody can consume them. And the items now include explicit labels. So for example, we can group them later like feature documentation tools. And yeah, I applied all my expertise with JavaScript and implemented filtering. Yeah, basically I had to Google a lot. It still looks terrible, but especially in such cases, but it kind of works. So I will probably exclude categories where there is no labels and then it will be fine, but yeah, this is how it looks like. And later I also plan to add filtering by seek or subproject so that it looks a bit better. And for example, what I've done, I removed service categories. For example, here we had a lot of documentation categories, advocacy and outreach documentation, etc. And instead of that, now we use labels. Why it's important because for example, yeah, it's hard first. It was focused on user experience. So I put it to the user experience column. The same for example, for solution pages for user documentation right now it's here, administrative documentation, administrative column. And for example, if somebody wants to see what's happening with documentation, you click a box and you see that, for example, documentation for features is here, tools and services here, etc, etc. So yeah, that's basically what I have in progress. And yeah, I can add more filters later, but definitely there will be a massive match conflict. If you do something with YAML before this pull request. Maybe we should wait to remove it until this pull request is merged. Like you merge it and then I should have a PR right behind it to do the actual removal of this roadmap items for our so yeah, we'll appreciate any reviews here. But yeah, my target is to measure it. At some point maybe over the weekend. Yeah, after that. Yeah, so next Monday or Tuesday, we can merge pipeline. I also have a lot of other items to it. For example, dark theme or yes, they've agreed on terminology update. It still needs to be applied. But I want to merge this one. Can you drop a link into the meeting notes with the link to that pull request. Okay, we'll do it after stop screen sharing. Thank you very much, Oleg. Yeah, any questions before I stop screen sharing that Nothing for me. And again, if somewhere there has items, for example, I know that there is a script security interface reward. I'm not thinking about taking it to there, but if you have other examples of such important features for users, we can add them here as well. Any contributions and suggestions are welcome. And if you don't want to go to just drop it in the main increase the link from the job, so that I will incorporate that on my own in my future pull request. Awesome. Thank you. Okay, just a second here. Okay, that takes care of that item. Let me just make one more note. Let's see, Mark, think you're up on deck next. Just a shameless plug that the dead and mess bomb is also on the call and we're planning to add symbols to the get plug in as part of get plug in 4.3 that were released roughly the same time. We hope within a week or two of the two dot 235.1 LTS. I'm not going to simplify the presentation, but I'm concerned about compatibility. I'm comfortable testing jcast compatibility myself but I'm looking for people who are experienced job DSL testers or job DSL users who will be willing to explore a beta release of it. So just a shameless plug looking for people to help. The pipeline is one of those things that I hope this will make it much easier to read get plug in in the pipeline script context because instead of references to classes, it will use symbolic names instead. Very nice. I do not have any cycles, unfortunately, to test. Yeah, no problem. Just a plea is a request is a good thing. Yes, definitely. Anybody does jump on in. It takes us to the end of the open items discussion. Does anybody have anything else they wanted to bring up nothing specific. I had a generic question about pipeline plug in plug in change logs. Okay. Because what I've noticed that we have many pipeline plugins, which haven't immigrated to get hub releases or change lock and we see it. And why it's important. We have a recent update on the flagging side by Gavin Morgan that plug in site now displays change logs right inside the web interface. So, it would be great if we were able to update pipeline plugins to use one of the standard formats so that we could source this program format and display on the website. It's mostly for me but I mean historically the main reason for me is that I find from my use cases release chapter is like quite annoying to look at because it uses the format like when I'm looking at change log. So I'm usually looking at historical releases trying to track down some old bug, you know and some release six years ago that I wish I'd never had to look at again or something. It's like when I'm using release chapter right there's like pagination and there's a ton of white space and it becomes a lot harder to compare version to version. So I just kind of never really felt motivated to make the change I mean if it's important now for it to show up on the plugins page automatically then I'm willing to go ahead and do it just before it was kind of I didn't really see any benefits. Yeah, so just to clarify, if you add change log MD. It's also fine. So it doesn't change like MD. Okay, some plugins don't get this source of my confusion because some plugins still put it on the read me page. Some plugins seem to still have it on weekend. So, yeah, it was just browsing through plugins a couple of days ago when I was trying to resolve the basically play pipeline plugin some great issue I hear. Do I have do we have to do something specific so that change log MD shows up like, for example, I looked at the file workflow CPS, which has a change like MD file but the releases page looks to be blank. Yeah, so change is currently not supported on the plug inside, but there is a ticket for that. My approach here is that change look MD is pretty much standard format in open source projects. So we should support it on the plug inside. And yet I believe that we will just do that. I'm not sure how exactly because we can. There are multiple ways to do that, including with just a dump half of the dependable course so that it results everything for us, or doing something on our own but it's yet to be implemented. So it's important I can use really structure this until now like this is a more important reason for users to actually be able to see it in automated way until now I didn't seem as important. There's probably some plugins to like that. I don't ever really look at that probably might still have their change logs on the wiki but I don't know. I will check my notes and report issues if I hit them. But for me keeping change look MD is perfectly fine. We will just need to apply some magic to identify these files. Because yeah right now we rely on metadata supplied by the update center. So we either do some magic on the update center generator site or we update the moving HPI inject additional metadata so it's yet to be seen. But yeah change look MD might be fine. This has anyone tried creating an automated script to backfill release drafter with old release information from like a changelog MD file. And there are tools for that. So there are tools which allow migrating from change look MD to just get half pieces. You don't have to use release drafter for that. Yeah, makes sense. So, but, but I certainly haven't done that with any of the plugins that I maintain, and I haven't had any complaints about having just drawn a line in the sand where after this point I use release drafter is that still okay, that I just change change log that MD records all the things that used to be in the wiki and release drafter started at some point to record things for new. I hadn't bothered to do any transition is that I assume that's okay. It for me it's more personal thing I just wanted all in one place. Got it. I see. Okay, I just read through all change logs often enough. So, change look MD has a lot of benefits on its own. For example, if you do not want to rely on GitHub infrastructure, then using change look MD, it's just using it. If you go to GitHub releases, etc, then basically your change logs are all in GitHub tools for us. We are already all in. So, I'm a bit relaxed about that. But yeah, I understand maintainers who prefer change look MD. Okay. Awesome. Devin, you'll just take a look at that. Yeah, I'll make sure that at least we have changed like MD for all the main plugins. Okay, awesome. Thank you. So, does anybody have anything else going once going twice sold. Okay, well that will conclude this meeting short one I will give everybody back 30 minutes of their Friday. Do you have a good weekend everyone stay safe, stay happy. And I'll see you online. Cheers everybody. Thanks everyone.