 So now we are being recorded and now I'm going to make a host All right, this is a me my first pipeline author and sick meeting a little while. Welcome everyone I'm Liam Newman. The other people on the line are I think I think I don't sorry I Not sure we are still being recorded because I have a pause recording a stop recording option here, so yeah And flat silver If you don't want to be recorded you can leave the meeting now and that's okay as usual the Jenkins Code of conduct applies during this meeting and Welcome everyone we'll be talking about Papua Miss Yamal the meetup that we'll have next week and It doesn't actually say on there, but I also know just put this on the list of things that I'd like to have us continue to Make progress on as the Having an ID in the VS code for pipeline. So Let's get started Oh Or actually, I don't Let's see if you want to talk about the meeting you're gonna have or is that really just the sum total? I mean just I can share my ideas about the meeting on the 20th of July. So I'm planning to prepare some two or three pages of slides About like the some basing information about the pipeline how it is working with what features are implemented And what are the next features for the next intermentation then I'm planning to switch to hands-on Examples tutorials with an and with an example repository so it will be just like an Tutorial something like that and also after that it will be nice to have some questions or feedbacks of course I Think that's all from my side The hat there's the link to this is I believe in the notes yes, so excellent and If and I will make sure to share this out on Twitter once again on my Twitter, and maybe I'll do on the check it further as well to make sure people are aware of it One of those when you know those you announce it again kind of things. Yeah Yes, you got a good number of attendees though. That's good. Oh, that's awesome Yeah, so we can get a bit more for sure But definitely we will have some audience there good. Um, yeah, thanks to it. Don't share for Presenting because your pipeline is young of this interesting topic. Yeah So, um, let's see here the the thing I'm I would ask maybe I don't know if you want to send Post the the slides. We're some early feedback and I Can do it tomorrow. Is it okay? Oh, yeah, totally. I just mean that way we can and I Guess my question is is are you Are you pretty comfortable doing? doing the The presentation just straight up or do you want to do a practice from it? Um No talking so it's not a big deal, but I just yeah, I feel comfortable. I mean I did some presentations before so Yeah, I think yeah, but of course like checking the presentations from another perspective, it would be great because maybe I Mislead something No, no, that is what I'm worried about Usually what I think about women when doing the presentation is just Whether or not you know, it's like they're comfortable and they've got you know, everything that they need so but sounds like you're you're on top of it So that's great. Yeah, I'm good. Okay, great Let's see here Mention about the presentations that Jenkins online meetup is contributor driven event and we mostly focus live demos show and tell So The most important part is the demo site not the slides, etc. And There is all to be able to go to them as the repository. So I think Okay For that I'm planning to create another separate repository with some with simple application Which is may even buildable and also I'm planning to write all the pipelines which I'm going to demonstrate in the Presentation so everyone can just easily Go on to the post today and check the definitions the Ml files or even the build the project itself awesome That that sounds great and that'll work a great is a long-term sort of example. You can point point point people to so Cool All right, well sounds like we're ready for that Let's see Tech-con pipeline trigger plug-in demo Yeah, so it's just heads up for everyone There is an ongoing discussion spot having support for tick tone Jenkins and The Ctc we plan to have a first the demo of the proof of concept So if someone is interested, please vote for time slots. We haven't fixed the date yet It will be as sometime next week And maybe quite simple to be able to run a tick-con pipelines and Jenkins And probably it will be a tick-con pipeline step which can be invoked from the Jenkins pipeline So it's not something Replacing pipeline to say it's a community to just trigger execution on other platform Similarly to how many other great It might be interesting to see the members as well Yeah, so I guess these are two main news so Yeah Trigger plug-in also if you read The seed my dentist mark announced that he will be stepping down as a seeker leader is unfortunate, but side to see him go but that But as I understand he's doing well overall and Just Basically a choice that he had to make so Anyways Yeah, so anyway, I think that we should keep a basic running Achievements from the past months and we keep we should keep pushing them probably onboarding Topics and more contributors Anyway, thanks a lot to mark it for all the contributions over past months basic Yes, absolutely So, let's see What else the other thing I wanted to sort of make sure I don't know that I don't think he started this thread I need to go back and look the Mailing this threat mailing this thread on the IDM. I will take that on it's something that's Near and dear to my heart in pipeline that I will get that started this week That's a lot of action. I don't know if you want but that's There's actually several several like ID plugins for VS code that claim to do pipeline right now and it's sort of unclear. It's Every time you look at one thing is that a is that just a wrapper around the the declarative Linter or you know, what what's going on there? So there's a there's several that going on there It may be a matter of looking at what what's available and seeing if there's one that we can contribute to or pull in one through Linta For a contributed into the Jenkins org as opposed to keeping their own. I don't know Yeah, the there's the linter one that's 39,000 yeah Jenkins file support. That's the one I was thinking of but Anyways, and it's one that we have to sort of go look at and review each of them to say what What's doing what here? Right, oh, maybe we could even consider starting an official plugin For example, similar to what we did this configuration as code plugin Obviously, we're inviting contributors and maybe seeking options to fork something because Yeah, having multiple plugins is great, but having one plug in this stronger communities also a great opportunity for us Yeah, what's interesting about some of the some of these are the plugins is that they're using the Jenkins logo And I don't know if they came up in the Meeting in terms of being Or is or is the logo sort of generally allowed to be used for open-source stuff So logos allowed not only to be used for but open source but basically for any stuff because all logos are provided this creative comments to you should share like three to zero Right. So what it means you can take any logo listed here. You can use it as ease or You can modify it You're required to Refer to the original source Not everybody bought this to refer to original source, but at the same time in many places, it's not easy. Yeah Personally, I'm not too concerned about that But yeah Something which may be a problem Yeah, the only reason to be concerned if it relates other Jenkins rules Everyone is welcome to reuse these logos. Yeah, okay Was been a little bit vague on on on that. So thank you Install one of these plugins. All right. Do we have anything else to talk about today? Yeah, maybe one related topic to the logos so I Right right now slightly about updated the road map. Okay. Yeah, so the reason that Wednesday we had a governance meeting and this this governance meeting to be approved publishing for the road map So I just wanted to clean up all items to ensure that they have Documentation, etc. So we have pipeline development and IDE. So in this it's in the scope of Whatever VS code or maybe other plugins But yeah, right now, there is no explicit description of what it would mean So what I did there just redirected to the sick page because basically it's what I was the best effort right sure but if the outcome of the discussions is having more details and Putting let's say some information on pipeline altering sick page like listening projects like we did for the six Okay, I Will check this page also because there's an issue which I plan to do in the next releases to Enable some intelligence plugins for writing pipelines as Yama. Maybe also you can include it. I don't know Just an idea Yeah, totally Okay, so hey having that linted. Do you want to have that discussion now in terms of adding these things as projects or Over oh Why not I can just show you an example of what we do so In other six we started Sections which basically summarize main initiative is being driven by six for example here You can see that there is plug-ins plugin site integration this beat up User guide reward administration guides searching kids on kubernetes, etc We just listed the idea and it puts the kind of landing page and we gradually extend this information so that users and potential contributors may find more information with the guidance how to contribute and Also, they could understand the current state So basically the purpose of road map is not Only to show it to users but also to show it to contributors so that we can highlight Okay, there is an opportunity Okay, and Yeah, in auto-rank seek Could do something like that A few projects Sorry Yeah, but basically that's what we could do here Vacation's been yeah, we don't have a product we don't have a project section. Okay Well You see pages are not required to have them but it looks to be a good practice. So, for example, you have the same for advocacy and outreach To some extent we have the same for cloud native seek though. It is a massive update Yeah, in principle if again, it helps that is the Exit on to what the main projects for the sea Okay Do I know that we want to like work through that right now, but I can take that as an action item for like next time to Fill it to create that. Yes. I'm good Okay, so You have a lot of time does anybody have any topics to discuss just Yeah, maybe I can ask something or like After the meetup, I'm just planning to wait like one or two weeks to gather some Feedbacks or the usage feedbacks about the pipeline is you know, plug-in and after that I Think we can just There is it with version one but also it is important to get these feedback from the community itself and also seek So what is your opinion about that? so Personally I would prefer to test it a bit more Yeah, but yeah two weeks sounds reasonable but I wanted to spend some time in May and June on testing pipeline as YAML Unfortunately, he didn't go as planned because he had this major infrastructure outages and other interesting thing Yeah, so I would have preferred to test on the plug-in Yeah, maybe the end of August or maybe September. Okay, thanks. Yeah, so For me the main objective right now is not to release it because Remaining incubating stage basically indefinite. Yeah, it's already the start of the users, etc Yeah for me the main objective would be to actually facilitate the adoption and feedback at the current state. Yeah so for example You talked about demo repositories, etc We can do that. We can do blocks. We can keep adding features and Yeah, for me a one-to-zero release it makes sense in principle, but you personally I wouldn't hurry right now Enjoy the freedom. I mean like right now before you before you go 1.0. You're free to go whatever direction you need to go Yeah I can switch to Jason. Python is Jason. Yeah, there you go. Some of the projects Jason. That's it That's what we really need I started testing it today. So basically I tried to deploy it in my configuration spot environment I hit some issues So I just submitted a few patches But for me the biggest problem was with dependencies and these Basically dependencies so here I updated to plug into my articles and Jenkins core bill of materials And actually it reduced the footprint significantly and it also reduced list of actual dependencies from 15 to less than 15 Because it was including let's say pipeline aggregator plug-in here. So basically it was Firstly pulling a bunch of dependencies and secondly, yeah, I hope that at some point you will have the plug-in aggregator on its own so It would be better to just cut to this circle dependencies and Yeah, I cleaned up a few other bits, but generally it's the main cool request and After that, it looks quite good. Right on. Thanks Appreciate it because I'm not so much familiar with the This dependencies, but I will use it as an example for my other Pipelines like leggings. Yeah, cool. Yeah for bill of materials. We still have a lot of limitations. So for example pipeline model definition it's not in bill of materials and For your information beam, I just reported a defect there because it uses go a version higher than including the Jenkins core But did you see my comments all like I don't think it actually uses it. I think it's only an issue in plugins that depend on declarative and maybe only in certain cases But I filed a PR. I don't I don't know where you were testing it But if you can test my PR that'd be good So in my case the problem is my test environment that it's driven by configuration as code, but it also driven by Maven and Deliberately enabled enforcers there. So for me, it's a pain to add plug into my test environment these days But at the same time it allows to discover a lot of issues Yeah It has what Okay, well, I don't I don't know I'm confused about this for a number of reasons But I guess the big thing is that this hasn't changed for like years And I haven't seen this personally in other plugins that depend on declarative. So I'm wondering if there's something subtle going on Well, I don't think that there is something going on because in this case you can see the dependency tree is different So it's not a plug-in. It's Jenkins for runner Basically Depends on Jenkins core explicitly. So dependency tree is different and maybe Maybe having an explosive dependency on core makes it different. Yeah, I don't know. Anyways, I filed a PR to maybe suppress the issue, but I Don't know and I have a chance to test it. Yeah Yeah, so But yeah, thanks for that Anyway, in my case, I just excluded go over. It was the easy part But yeah, it is such a case. You never know when it explodes. So I mean, it's just Generally good practice Yeah, I was just surprised that I didn't see it in declarative itself And then I when I was looking at I noticed a bunch of other weird dependencies that were kind of this similar where it was like Should we start excluding a lot of things? But Anyway, we should also think about updating go over in the Jenkins core because 11 like something like 10 years or so Yeah, that I brought that up just a little while ago in another Another discussion and the this yeah, it's a great idea. I I've also been informed that it it would be an insane pain and a pain to do And likely well, or likely breaking for many plugins So maybe you have seen this pull request Just to give you motivation up It's just security So if you can do that, we can definitely do go over But yeah, the amount of effort is quite high for sure Okay, so yeah back to pipeline out then Actually while While I'm doing that We'll try to you bet pipeline is YAML in the Jenkins file runner Actually, I already did it and the patch was quite simple Okay, because the Jenkins fellow runner has full control of what it does. I think story to ensure the API is almost the same So basically now it just checks for the it's YAML or not and takes different the flow definitions Obviously, it's just a first step because in the future, I'll probably need to implement better APIs But Python is YAML works there for hello world after that So and then they're pushing that for Jenkins fellow runner would be interesting because yeah In this system, there is a lot of YAML already. So yeah, maybe it will help us to facilitate adoption totally Yeah, cool So it's gonna just draft though. Are you I mean, what else do you need to do there? Well, I Asked a bunch about the release. Oh, okay So for me, there are still some my issues in the Jenkins fellow runner To be tested before I release it but hopefully So if my plan is YAML is at least today, I will be able to pull it So it really is it by the online meetup as well. So some testing and possible updates. That's why I I will release it after the meeting. Okay, great And yet for me, yeah, just A Testing by plans YAML. I think it would be the main priority within this story because jinx fellow runner part is quite simple, right? But the pipeline is YAML. It is a bit more challenging because he had also has converted part It's quite complex. I haven't even touched it yet. Okay Yeah, the execution part Yeah, the syntax looks good to me, but getting feedback on syntax is probably also something Yeah Especially I'm not sure what we would like to do these regards to Jenkins pipeline YAML and Jenkins X pipeline. I think that the rest of the opportunity is for some Syntax reviews, but it's probably for future stories. Yeah So Yeah, I guess that's it. Okay. I Will tune. Do you have any other ongoing work with pipeline as YAML? Yes, these are the issues that I'm currently working on so But mostly I'm waiting for the meetup. So especially the feedback is more important especially for the usage part and also I'm planning this another converter because I implemented one converter which is converting pipeline as YAML to declarative, but I'm planning to work on the vice versa. So converting declarative pipelines to YAML format, but Maybe I need to think about it because I Need to somehow pass all the model AST elements in the pipeline model definition to be able to make it YAML format But also this Pipeline model definition has a converter into JSON. So maybe this can be a question Will it but will it be better to implement this model AST to the YAML in the model definition or should I implement myself? Because there are some logics while converting this model AST elements to YAML for example converting functions or agent definitions or there are some logics that I need to implement but so So the So the pipeline model definition plug-in does the the JSON conversion there. It also does It does JSON to groovy and groovy to JSON. So it's a full round trip then I Just checked the plug-in this plug-ins code and I saw that while it is converting to JSON. It checks some Definitions like for example the agent definition. Is it defined like with node name or is it just a label? So from the YAML part, I'm going to implement the same logic there because also it should be like a bit similar So that's why I wasn't very sure about that. I was going to ask it after the meet-up maybe so How we should proceed I can easily implement this conversion in my plug-in Just I wasn't sure like if in the future if some logic changes in the model definition pipeline Then I should also implement the same logic. Yeah. Yeah, you probably would end up needing to I mean right now Anyways having it in your own plug-in makes sense because then you can just you can work at it on your on your own speed what we've done on the pipeline model definition plug-in side is We have a whole bunch of tests to guarantee for round-trip behavior and all that other stuff for everything so That would that would involve being like I mean that'd be a great great place to test it But that that plug-in is also already pretty test-heavy. So the the build on it is pretty long I mean, I am working For implementing myself That's totally fine for me. Just I just wanted to get some opinions from you guys So if you are all agree that hey, okay, please go through with the pipeline is your more and In the future if we change some logic in the pipeline model definition, we can just easily implement Or change in the pipeline is him. Yeah, it's good to go. Yeah, I think keeping in your own plug-in will probably be easier for you We just need to make sure to add some kind of test to the Some test run to the pipeline model definition plug-in that picks up when once you once you Go one certainly by when you go 1.0, but probably something sooner than that is to say hey When you should run a few tests from pipeline from the pipeline is YAML when we're building pipeline model definition to make sure that we aren't breaking it Yeah One of the options and the current in Jenkins We have support for that. So there is plug-in compatibility test that right exactly that's On plugins so we cannot do forward compatibility test Yeah if I understand correctly This the question is only about YAML part because Yeah, if we can use pipeline model with a definition to retrieve Json and working Json to YAML is we see now quite Yes, it also Exports lots of unnecessary attributes. I mean not unnecessary, but not related to YAML So that's why direct the converting will make sense Okay, okay Thanks, I Will check this compatibility plug-in tester. So PCG. Yeah, okay. I will have some idea All right anything else a Little early, but from me All right, so yeah, maybe one thing which I will finally put on the roadmap So there was an item for pipeline integration testing We removed it from the roadmap because there was no clear What would be there? That was a different one mission I think that once the jinx fellow runner is released said I will probably Revisit my experiments with integration testing with jinx fellow runner. Okay, because you know what I already Do for example, you know the code base we have two frameworks there And actually I was able to get the jinx fellow runner running from J unit So for Java developers, they can simplify that Yeah, maybe it will help this pipeline library testing because right now for all new usage testing pipeline libraries quite difficult example right now we have a pull request for testing warnings in G and it's extremely difficult to test it on this pipeline unit because pipeline unit doesn't test real behavior All right, so I hope that integration tests will be Sounds good, so you'll you'll add that to the roadmap and be Taking a taking a look at it at least Maybe maybe so yeah, I can show how it works and jinx fellow runner if you're interested, but it's really simple Okay So if you want I can just show it quickly Mostly switched to visual studio code for development Sounds weird Okay, so here in jinx fellow runner now we have vanilla package, which is basically Powered by bill of materials, etc. It's just a package with all standard plugins including scripted pipeline declarative pipeline and a few other bits and There is an opportunity to test it now. So there are some test utilities, etc But yeah after that test and pipeline in JUnit with jinx fellow runner looks something like that. So pretty much similar to common unit tests you just declare dependencies on proper components and Jinx fellow runner can start these dependencies to declare it in form xml and yeah, just that's exactly the end of stuff So basically yeah, how it looks here in form xml There are some components which will end up likely as a single model You also declare dependencies on your plugins which you can use and you can see no versions because it's from bomb After that, yeah, just a few test utilities and you get jinx fellow runner running But yeah, the problem they use plug-in combinations or a single plug-in sets Just a minimal JUnit. You can use a test container some other bits for emulating test environment and Yeah, use all these tools you can Wait a week to test pipelines and Yeah, just Yeah, I should have Some real test here in bullet or not So there are some pipelines like that basically also hello world styles, but a bit bigger than the usual Yeah, they get executed. So I will gradually move for some more of tests and probably it can be called this integration test framework later Once everything is integrated Yeah, it's still potentially a white box test and because you can access Jenkins internals from the same test But it's rather for advanced users not for common pipeline developers There'd be an option would do that. How hard it would be to make it something that people could use more more generally I mean what you can see Sorry, how hard how hard like you're saying it's for advanced users what it seems like something that that could be useful for It's not beginners, but like in me look at what What what needs to be done what would need to be done to bring this down this minute that would be easier for people to use So I want to have test rules and I want To just have a permanent home or whatever which integrates all the stuff So that basically you just define your dependencies You want you can also define your configurations as a jcask So that's how we do for in performance tests for Jenkins now Okay, and it's just that test rule, etc. And it provisions Well, basically a jenki's fellow runner environment And the executes it. Okay, so Well, it's Well, you could probably do the same without a jinx fellow runner at all It's just engine which already embeds a lot of stuff, right? And yeah, maybe So it's quick implementation and maybe more complicated implementation is to actually have something to use out Java So we have a jenki's fellow runner test framework, which is basically SH unit too, but it's quite complicated now So maybe having something in the middle on Java, but again quite simple to use Integrate with existing test framework Then yeah, you can also use it for integration testing but you have Personally, I would rather use the Java or other engine which is compatible with test containers because it's much more convenient to test these environments after that Okay So not sure when I get to that But yeah, in principle, it's quite easy to get it right So it's a small matter of programming to just create documentation and APIs Make it useful. Okay Okay. Well, I think that's that's good for today We're coming up on time. So let's thank you all for joining us here and We will see hopefully whatever on Monday and then again next Friday And I will go ahead and stop the recording