 Welcome everyone. This is the Jenkins UX special interest group. It's the 14th of April, not the 13th. Topics that I knew about on the list pending UX changes Tim won't be able to join us today he's not feeling well. But we can talk that briefly, multiple pipelines for a multi branch job. And Uli since you're here I had one on Jenkins online meet up for an environment setup. Okay. I think you and I had talked about it briefly in an earlier call and I wanted to, if we could spend some of your time today to talk a little bit more about it just to be sure you're okay and then I'll take the lead on configure proposing it abstract etc. I just wanted to be sure that I'm not going doing something you're you say I can't even do that remotely mark. Anything else to put on the agenda. Yeah, I'm not sure if I'm still there because of my children but if it's possible. I would like to talk about a project I am having with a student. It's about pull request view for Jenkins. Excellent. Okay. Great. Okay. Well and I would propose there is nothing wrong with us changing the order of things in this agenda I put you first on the list Uli and and let you talk to that. Unless Damien you have a strong objection opposing that. Okay then let's Uli let's do that any other agenda topics we should put on the list. Let's put this one up as well really just to assure that while you're while we're confident you're available we've got it and then if surprises happen. Okay, go ahead share with us. So, actually we have, or maybe it's a good idea I shared the, I can't share my screen. Can you let me share my screen. So, let's see. I think everybody knows the details of Jenkins so we have typically projects where we have branches and pull requests and when or my warnings plugin I'm always looking in the project view that means I step into one of these projects. And then you see here a lot of, yeah, let's say trend charts, etc. This is the project level. And then we have the build level where we can see the details for each build. And I think one important thing is totally missing in Jenkins and that is a few where you see the details of a pull request. And let's jump a little bit here. So, let's pick a pull request here just so I can. Okay, all are broken. I don't know why. So I just pick one. So if we open a pull request. What we see here in Jenkins is the same semantics as in all other jobs we have here a few of the job which actually is the pull request. And you see this is basically the same few there is nothing special in it that means we have here a trend. And this is the trend of a pull request which makes no sense in my opinion. And if I go into the details. I see the details for the builds of the bull pull request. And here we also see a lot of details, which are actually not related to the pull request, which are related to the master branch. So, what I started. Yeah, sometimes I go, for instance, I have such a reference build where we can see which is the branching point in the master. And then we have a lot of warnings. And yeah, additional things from the coverage reports, the tests. And yeah, from kids, we also have some information. And one thing which is missing, I think, is to have some kind of data information for pull requests. So I want to see which, for instance, here from kids I want to see what are the commitments I've done since I started my pull request. I want to see what is the tests that I have added in my pull request and which are failures from my pull request which are failures not from my pull request. And the same for the coverage, which is the code coverage of my pull request, and which is pull code coverage of the whole project, etc. Or I want to see which warnings are new in the pull request and which are from older builds. So, this is basically the information I want to provide in a new few. So what we are trying with the student is to replace this build view with a new pull request view, a delta view, where each plug in can provide some kind of delta information, which is just relevant in a pull request. So this is the background and we are trying to create this new view in a green field. Let's say we just created a new view and we want to have a draggable items where we can say, okay, I want warnings into this view. I want test results. I want coverage results or get commit results and each plug in can contribute to this view. And you can reorder them with drag and drop, etc. So this is something we are currently trying to develop. So, if we have something to show, I will bring it with me. Currently, we have just some ideas. And, yeah, I think it's important for our UI meeting. So maybe some others have ideas what would be interesting for such kind of pull request view. I think that's brilliant. Okay, you didn't mention one of the gaps that has annoyed me for a long time is already at the very top of the screen where it says pull request 11 PR-857. 857 has no meaning to me. So if I could pretty please find a way to have that be text from the, from the pull request description or something more useful than I love what you've described the notion of a delta view showing me here are the things I changed and how they positively or negatively impacted coverage or tests. I love the idea. So, I think this is a really a thing which is missing. Now I'm working with GitHub actions in parallel and there you'll see just the information which is relevant to a pull request. And the name, for instance, of the pull request or the number of comments from others review comments, etc. This is information which would be useful in Jenkins as well. Now, now as your students considering this, the, the SCM API presents them an SCM interface for these kind of things. I does it have a concept of a pull request I think it does, or is maybe that's the branch API but you're a student having to add new APIs as well. And is there is there a bigger picture that this possibly would, would ask for a JEP to for discussion or is it rather mostly UI. What are your, what's your sense there. The problem is we have a strict timeline of three months for a bachelor thesis. So, my idea was to make a kind of individual plug in which shows the possibilities. And if we are finished with this bachelor thesis, I think we can take this plug in discuss it with some other people and try to create some new API's from it. So, normally, yeah, it would be good to think about the API's first but I can't handle it in a bachelor thesis where we have a strict frame timeframe and students write the text as well. So, I think we are developing it in our small plug in first, and then if that is working out and looks good we can take the next steps to provide it as a bigger thing in Jenkins. So, and that that sounds ideal as well that sounds just great. That fits well with the technique Tim use to develop a first prototype of pipeline visualization right he put something together and put it out and said hey let's talk about this thing. So that's that's just great. Absolutely. This kind of sandbox where we are now. And we have done that in another approach as well where we implemented the extension point in our plug in itself so nobody or we do not need to wait for pull requests and things like that. Excellent. So this, this project, go ahead Damien. I have two questions that are more curiosity than something else. So the first one is there a reason for not using the GitHub pull request view that can be fed for by Jenkins build using the checks API meaning Jenkins during the different steps like when it gathered the test results the trends, then you could add back a comment or a check content on the pull request view so the information about that pull request will be view on GitHub pull requests and not on Jenkins site is there a reason. I don't know do we have a pull request view in Jenkins. No it's on GitHub. The idea is that Jenkins connect back to GitHub. Okay, we already have it on GitHub. Right, but but GitHub is only a static UI and here and Jenkins we can have a nice UI with JavaScript drag and drop and what we are planning is. I'm not sure. I remember the name correctly. Let's see if I find it now. Oh the goal is you want so so where we can make information. I want to have it in a UI with JavaScript and everything which is your static. And I want to say for instance I don't want to see this reports then I click on X and it's away. And if I want to add them again I click at. So it's kind of dashboard. Custom dashboard to customize the view. And is it per user is my understanding correct meaning for a given job to different user might want to see two different things on the same pull request or the same job. Yeah currently we will that's the point. We will start with a common setup for everybody and we can change that per user. Interesting. And if that is working out good, we can use the same concepts for the build page as well. Or for the job view, the drag and drop support where we can, because this is something which is horrible now that we have these charts on the right side and I have so many left space here in the middle. So I want to drag and drop these charts where they have place. And this is a library we want to introduce in this new view, but this library can be used in this view as well. That's really interesting that's really a big shift on the way Jenkins use to show thing, because my second question that you answered by the way was about the configuration of the job. It's a bit like the handle when you use job DSL for instance but in fact it's not the point your point is that it's very user meaning user will want to, it's a bit like the favorites in blue ocean but way more powerful because it's a custom dashboard. Nice. That's really nice. Thanks for the answer. Yeah. Okay. Any other questions. I'm sure if, if I'm not the one who asked that others will. When can we first see a prototype this sounds really cool. Are we are we weeks or months away from a prototype. What would you like to do. I've already seen a prototype of the drag and drop without content. So what we have is a check style box and find box box where we can drag and drop this is already working. The only thing is this is not an extension point with real content. It's just the drag and drop is already working. So, and I have a meeting with my student tomorrow. So hopefully it is still working. And maybe we can have a prototype in the next meeting or in a month or so where we can see if it's at least something we can show. That's excellent. Thank you. That's great. Anything else really on the on the pull request viewing the this this fills me with optimism. That's really great. Yeah. No more details so far. So, in an earlier session, only you and Damian and I had discussed. One of the topics you had mentioned was that you've learned that it helps your students and others contribute to the warnings and G plug in if you provide them a dedicated preconfigured development environment and you've got a repository that tracks that and my thought was, I'd love to have a Jenkins online meetup just doing a question and answer session where let you. I would open it say welcome we're grateful here and then have you give a brief overview and then let me ask you questions and probably have Oleg ask you questions as well so that so that we just have a dialogue about your environment set up and what it has helped and what things you found as barriers strengths and weaknesses. Would that be okay for you. That would be fine. Okay, so, so I will send it usually it takes us one to two it typically takes us two weeks to get an abstract approved and a date scheduled so it would probably be early May, before we would do it. I don't copy you on the abstract, but plan on me sending that within the next, say, two or three days by end of this week I should have that sent. Okay, that's fine. Great. Excellent. Making notes. Okay. So then the next topic was pending user experience changes. So he doesn't have capacity right now to do further work on it. What he was doing was adding changes to the UI that were outside of forms, but still using tables for layout that they need to be transitions to divs and he started the initial proposal. But right now he's he's not got the time to keep driving it forward. So my hunch right now is it will probably pause. That's that's okay I think that's reasonable. And then we hopefully will have time to pick it up in the future to look further at what can we do with more places to transition from tables to do this. He also had the pipeline visualization plugin demo that I haven't done anything with yet and one of my first actions now is I need to get that installed on my system and start playing with it. Others others I think would benefit from the same. Anything else on pending you exchanges. Don't think so. Okay. Next topic then Damian was on multiple pipelines for a multi branch job. You had a concept. Do you want to share with us what the current state is. I was in holidays since last time so I didn't have much time. However, I've asked more Jenkins users on the area I work for so I can, I still can be influencing them by my bs s, of course. But all the users I asked or discussed with were really happy of the concept of multiple pipeline per repository, even if the implementation is multiple way more jobs per multi branch. But everyone is not able to go back after training this on GitHub actions, because it allows to have simpler pipelines with different life cycle. So, everyone agreed on the benefits of that. The thing is that now I, the next goal is still, I need to go on a side chip pipeline and ask for that. Yep. So it doesn't change yet since last time except the way more user that could potentially be interested, which validates some of the initial assumptions. Mark, I think you are muted. Right. I should press that button. Thanks very much so further discussions will continue and and we we continue learning. That feels great. Any other topics we should cover before we close it looks like dirage was has dropped off. Only needed to exit Damian I believe we're done anything else. That's all for me. All right. Thanks. Let's call it in. Thanks. Should be available shortly. Thanks, Uli.