 Welcome, everyone. This is the Jenkins user experience special interest group. Let's look at the agenda for today. So proposed topics included a request from Chris Kilding to talk about multi branch experiences. Since Chris is not here I would defer this until later unless someone else has topics they'd like to cover on it. And then the on the other topic I had was pipeline visualization plugin demo that was done at contributor summit and talking further about it. Are there are there other topics you'd like to add to this discussion today. I wanted to add something that that came up present day, the ability, which is not possible today to have multiple pipelines defined for a single, let's say multi branch job. Okay, okay, so single multi branch job. Interesting. Okay, so single multi branch job, not. Yes, for a multi branch job. You can remove single because I find it confusing in my case. Okay, got it. All right, and I just paged myself out of the place. Sorry, just a minute. Okay. All right, topic added. Great. Any other topics we need to add before we start working through the agenda. Okay, great. So just a reminder then we've got this pipeline visualization plugin demo that was done at the contributor summit by Tim Jacome. I propose we not go through it again. Just feel free to click that link, it will take you right into the video at the exact time where Tim's demo starts, you can watch it and be amazed at. What it does if I understand correctly is it extracted a portion of blue ocean into a separate plugin that does not require blue ocean did I understand that correctly. Blue ocean is not required. And, and yet it's it works, and it shows a visual, it shows the same visual view of the pipeline as I'm accustomed to seeing when I look at the pipeline with blue ocean. Right. That's my understanding as well. That is correct. I'm adding the link in the document to the prototype plugin. Oh, good. Right. Okay. And, and you had said earlier that the prototype plugin hosting request has been submitted. I'm not really sure what is what is the prototype plugin hosting request. Is it something about having the plugin published on plugins. That's correct. So it adds it to the update center makes it makes it available to others once it's released. Okay. I think it's too early. My understanding of the Felix and then Tim's explanation are that it's a bit early. It's a kind of proof of concept. Oh, so releasing the plugin as it might have some downsides. I think he, sorry, I think Tim, Tim wanted it to add it to the thing requested to add it to the Jenkins CI or in GitHub. I don't know if he necessarily wanted to publish it yet. Right. Well, and, and adding it, the plugin hosting request does not require that he release anything and if he hasn't released it, then it won't be visible to update center. So, good. All right. Now, I think I don't want to, to speak for any behalf of anybody else but I think he also wants to have a very minimal scope and really and without a release candidate as soon as possible for an alpha. Okay, good. So, so intentionally scope limited. See, it should be, I would try to confirm this. Great. Release soon, and accept that it is, it is a proof of concept. Say your reason also we want to go about please confirm this with him. Right. Okay, excellent. Thank you. Very good. Okay. Anything else on that topic before we go to the next. Okay, then Damian multiple pipelines defined for a multi branch job. Tell, tell us more. So, it's a feature that was seen as a, it's a age case for many years in Jenkins. The goal is when you define a multi branch pipeline your use case is a hello Jenkins, can you watch this repository and do your stuff, meaning watch for branches pull request if you have if it's recognized as a compliant implementation like github for instance. And you have to specify one field or one setup on config as code which is the location of the Jenkins file which described the pipeline associated to that multi branch job. If I compare that process to GitHub actions in GitHub actions, you also have a repository. And you have also convention, like we say it's a Jenkins file by default on the root of the repo in GitHub action you have a dot GitHub slash workflows directory. And each YAML file found inside that directory are mapped to what they call a workflow, which is a pipeline in Jenkins concepts. This is really useful and we have a bunch of usages even inside our own repository, where you have different pipelines on the same repo. So they follow the lifecycle of the code, but they do different things. The main example I have in mind is one main workflow. So one main pipeline, which goal is for instance, to link and then chart and to deploy it to production. And that pipeline might have subtleties like, okay, if it's a pull request, then you don't deploy to production you only link. And you, you output D for whatever. So this is what we can do in Jenkins. And you have a second workflow, which is hey, every day at one o'clock in the night during the night. Let's run that process that check for the new version of dependency. And if there is a new version, then open a pull request with the updated version of that dependency. These are two separated process. And the idea of having one workflow file for each make it easier to maintain and to think and understand which task is doing what we can technically have one big Jenkins file doing the two of the two tasks with a bunch of conditionals. For instance, when the trigger is a con, then you run the update dependency stuff and open the pull request. And when the whatever the trigger is pushed code or manually launched by a human, then you do other action. So technically, it's not a blocker. However, in terms of user experience, it's really hard because you start to have Jenkins file, which is already a tedious syntax when you come from Yammer world, when you want descriptive. And everything is done to say if you want something complex, you need to move to scripted imperative. If you come to this from descriptive, one of the way to avoid the tedious maintenance or the imperative programming is to have simple and tiny files. Each file is only doing one task, but it does it well. So here that's a request I've seen already but was considered as an age case. And I have no idea I'm sure that topic has been blocked most of the time. This could be really an interesting value. Why now, because with the rise of GitHub actions and the use case that it started to use, I tend to see this use case done by us as a community on our own repository on GitHub actions, which means there is a user needs that could be addressed. I have no idea of the complexity of the task on Jenkins and I'm sure this can be pretty tedious to implement. But the goal is to bring that subject up to see what are people thinking about that what could be the solutions, etc. But I thought that this is really user experience thing. And I wanted to have feedbacks and proposal on that. I personally would agree. I think it would be a great improvement. I've also used data actions and having the ability as Damian described to have two different files, definitely improves user experience since it clarifies what, what is between which file, what is being done in which file. So it defines the two separate workflows, you can focus on one or the other. So yeah, I agree. And I think it is definitely a user experience thing, right. So yeah, and the person agree on that. I'm thinking of an alternative which can be done today also. If you are lucky enough to have a jikask or job DSL set up on your Jenkins controller. Then it means that you can define two multi branch jobs that points to the same repository with two different path for the Jenkins files. However, it means that the lifecycle of defining these files is tied to the job DSL seeder or to the jikask workflow. And in that case, the user experience would mean moving that lifecycle to the pipeline itself, meaning Jenkins watch discovered there are two Jenkins files or have a setup that say to Jenkins file. So you just have to watch again the repository to scan the repo once again. And this could, for instance, both seed only the second multi branch. Because it's not an issue to have different multi branch jobs, given the way Jenkins Prince things output things on the UI, but having something that makes it makes it easy to end user in particular an environment where the admin is not the developer. So you can watch your pipeline change it. But you need to request the administrator to update the Jenkins instance to have your second pipeline eventually restarting the instance which is catastrophic in terms of user experience. The goal will be what will be the path for an easy way to have this for someone with the correct rights only inside the repository. And I think I understand the concept you're you're sharing there because I've, I've used exactly this technique in the past to construct multiple. In my case I was constructing multiple multi branch jobs that pointed at the same repository because I wanted to test different different branch provider implementations but it's the same technique right it is. It's perfectly valid to have the problem is, then we have, we have scattered things into multiple multi branch folders that might better have been clear to the user if they were in a single folder. Yeah, I see your point. So how do you envision is this something you would take to to pipeline authoring sig or to some. What do you see as your next steps Damien. I don't talk that much. And I need inputs on that, because I'm not really sure about the process for such requests. So let's go to the pipeline sg to see what will be the limits and how it could be understood they might have already solutions in mind or started stuff that might be an history on that so that could be a good next step. I think the output of putting that subject to the pipeline sg will be, is it something that could be built within the pipeline concept itself. It's something that should rely on job DSL and G cask and another, let's say, smart setup that could be automated outside the pipeline itself and we will keep one pipeline, meaning one multi branch with one given file, but having a system that would allow the user to have multiple. And then playing with the visualization to maybe aggregate these views. Why not. But the goal is to know the limitation on the history of that request. Yeah, so I was, I was assuming that some, my simple minded user experience assumption was if the path to the Jenkins file were declared as an asterisk inside a directory, would that then from the user experience be okay that's enough. It says now create one job for every file in that directory. And, but, but I don't know if that makes any sense, because aren't there more cases where they may say I need different permissions for this, or I need different different configuration I want a different pipeline library loaded by implicitly for this thing. It's interesting that if the name of the job. Yeah, you can create the job by default. Yeah, we have to check the fine tuned back settings but yeah that could be a good idea. Not sure if not I'm not sure if the view could help on that because we already have three tabs on the multi branch job. You have the branches to pull request eventually the tags if you have set up your job specifically with this. And I don't know a tab that lists the different pipeline that exists maybe not sure. Haven't talked that yet that's that was a good point. Since we can create jobs within the folder of the multi branch that could be a way with a correct naming to support this and putting the asterisk. That's a really good idea. Anything else on the multiple pipelines defined for multi branch job Damian. No, that's all. Okay. Any other topics that we should have should discuss today. Looks good. Okay, I propose we call an end for today's session. We'll meet again in two weeks right see you then. See them. Bye bye.