 Yeah, so we are online now. So, welcome to the regular Q&A session for student centres in Jenkins Google Summer of Code. Today, I will be driving this session and we also have a number of students and mentors participating. So, it's a kind of unofficial meeting just for Q&A and we can just proceed with that. If you are interested about JSO plans, etc., we have another office hours for mentors and for JSOXA project tomorrow. Okay. So, yeah, I think we can just proceed with questions. So, yeah, if you have any questions, just ask them or just write them in the chat and then we will be able to answer them. Okay. Should I start, sir? Oh, why not? Okay. So, my name is Prasthik Gewali and I am interested in the JSOXA Artifacts Promotion Plugin Project. Okay. So, I have a couple of questions like, it was pretty tricky for me to understand the whole flow of the project, what is desired during the project. So, like, I just want to ask you that the promotion job that you are talking about, the promotion, new promotion plugin, that it should be represented as a promotion job, right? So, and that should, okay, and like, should it be created in such a way that it would encompass both the freestyle and pipeline projects or it should be a different job for pipeline only, like? Well, yeah, I'll try to quickly answer this question. So, probably I should just show you some code to explain why we are doing this project at all. So, yeah, we have, we did have a Jint and CI promoted builds plugin. So, this is a plugin which is widely used, but the main problem of this plugin is that it supports only freestyle projects, well, actually it supports all abstract project build types. So, please, maybe in the job days, et cetera, but it doesn't support pipeline and other similar jobs, just because it's architectural design, it was created long before the pipeline was created. The main problem of this project, what we have now is that there is promotion class and this class actually implements abstract build, though it's not a build itself. And promotion process is also not a job, but you may see that these classes hijack the existing APIs of Jenkins. So, you may see promotion process implements abstract project. And in addition to that, there is a promoted build property somewhere in the list, I believe. And the main problem here that it emulates a folder, although it doesn't represent the folder on its own. Yeah, here, job property implementation. So, you may see that it's item group in Jenkins. And it causes a lot of architectural concerns because, yeah, the class doesn't really implement how Jenkins architecture is designed. So, item group is supposed to be item itself in the most of the cases, but here it's a job property. So, many APIs don't work correctly. And this structure is also not really extensible if we talk about pipeline because, well, for starters, you may see that it includes abstract project right here. So, if you want to make it compatible with pipeline, you would have to rewrite almost the entire implementation to make it compatible with pipeline. And even with that, it would first break binary compatibility. And finally, the implementation is just not one would expect from promoting builds. So, the idea, instead of implementing this thing, is to actually have a separate job, which can be triggered from promotion. So, instead of emulating a kind of folder or item group for a particular job, we think that it might be better to just have another job, which would be a promotion. And then you could trigger this job from an existing promotion management. So, it was a proposal. A different promotion job would be created that will work for both freestyle and pipeline projects, right? Did you mean that? Yeah, it would be nice. So, when we talk about a new plugin, it would be great if it supports both job types. Okay, so for that, sir, the previously held promotion build plugin that we have inside the configure category, we need to copy that code into a new job, right? We need to refactor the entire process. If we need to make it compatible with both the freestyle and the pipeline project, a common job, I mean, a common job should be created so that it will work on both the sides. Yeah, okay, I understand. Okay. And sir, you mentioned something like triggering promotions as steps, like in pipelines. Yesterday, you mentioned triggering promotions as steps, which means like, as far as I can understand, it's like, after the completion of the pipeline, it will, a new stage would be included in the movie script, so that it will trigger the promotion. What would that mean, sir? What does it mean? Yes, it could be just a step. For example, you can trigger promotion of one job from another. So there are plugins like copy artifacts or release plugins Jenkins. And you could just implement the step which could trigger promotion of another project. And in such case, you could implement your pipeline which integrates with multiple jobs. It's one of the ways. Another way is that there is a step which triggers a promotion for the job itself. So for example, you build artifacts, you tested them, and then you trigger promotion which runs asynchronously, but you still trigger it from the pipeline so that you can trace the connection between projects. Okay. Okay, and sir, next question is like you said, defining promotion in properties yesterday, defining promotion in properties. What is its meaning? Like would it mean that inside the job section, there would be properties like environment that way it would be deployed later on? Yeah, right. So how common CICD systems approach, they have definitions, they try to implement configuration as code, and they try to put all the definitions inside one file. It may be a groovy file, it may be declarative pipeline definition, or it may be just whatever YAML file. But they still try to have everything in one place. And it will nest or have the same in Jenkins. Okay. So last question is like in pipeline will allow manual promotions also, right? Like we do in the free from projects will also allow manual promotions. And those things also be included in the promotion job. Yeah, right. So you can try promoted builds plugin. It effectively implements what we would like to see in pipeline. So yeah, you could add some enhancements, but yeah, promoted builds plugin already supports automatic and manual promotions. And yeah, I think if we could implement it in the new plugin, it would be really nice. And that the plugin that we have named promotion simple build plugin. So it's total function is just to trigger things manually, right? What is its main function? I couldn't get that the difference between promoted pipeline and promoted simple build pipeline plugin. Somebody tried to implement a simple promotion plugin. They started this project, they got some releases, but I would say that, well, they just implemented what they needed for the environment. So it's a subset of the promoted builds plugin. Yeah, if it connect as a source of inspiration for you, how it could be implemented, that's fine. But yeah, personally, I have never considered the simple promoted builds as a separate plugin. So the promoted build plugin also also has the manually triggering function. If I recall correctly, yes. Okay. Thank you, sir. Yeah. So we thanks to all others on the call. So my proposal would be to start from process questions. And then if we have time, we will be discussing project details, because yeah, I understand that many students here just they just want to discuss their projects. But yeah, the real goal of this meeting is to focus on the process. So does anyone have any questions about the process, about the applications, about the details, whatever? If no, we will just proceed with going through projects, if needed, and answering questions. Hi, Olin. So actually, I started working on my proposal yesterday. So I was thinking I was going through the past year proposals, they have like a concrete timeline about what they are doing. So we need to have a very hard and fast sort of time, timeline or a very brief timeline about what we are going to do. Because what they did was in the timeline, they particularly explained in each week what they are going to work on. So Just a second. Do you see my screen now? Yeah, I can see it. Yeah, so I will show what Nisar is talking about. Let's take whatever. Okay, so here you miss probably too many links here. Yeah, so there was the proposal, yeah, probably your reference, something like that. So here, if you scroll down, you want to find the loads, of course. If you scroll down, you may see that there is, sorry, I just moved the new laptop and it's really slow. Yeah, I just don't see anything on my screen so far. Yeah. Oh, yeah, we can. So yeah, you may see that there is some definition about the timeline. So the idea here that, well, you can define a detailed timeline, maybe on the daily on, if you want, but the problem that of course, you cannot match this timeline because there are so many details which we need to discuss. And what we have now in mind is that we usually expect students to submit a rough timeline as a part of the project proposal. So yeah, you can start from something like that to define main milestones. What we ask there are three coding phrases, plus community bonding. So there are four milestones. And for each milestone, you can start from defining deliverables. Because yeah, so there is a list of deliverables. She knew wanted to implement in this project. So what we ask you is to map deliverables to the timeline. It will help us to map the project once. So for example, here, let's say, in the end of June, you will have the trust coding please. And you can say that at this phase, you want to shift something like a couple of features, maybe plugin skeleton, maybe alpha release of your plugin, something like that. So this is what the granularity we expect from you. If you want to go forward and to detailize the things, it's perfectly fine. But we really plan to do some reality mapping as a part of community bonding. So you will be still guessing what you want to do because it's hard to estimate what would be the real time you will need for particular deliverables. So just take top level items from here and try mapping them to the timeline. It would be a good start for your project proposal. Hello. Hi. I wanted to ask a thing that I have made a sort of a proposal. I'm still working on it. Would it be fine to show it to you and the other mentors for the role strategy plugins? Yeah, it's perfectly fine. So what we usually suggest that once you have a proposal draft, you just post it and then mentors review it and provide feedback. That's why we recommend to start earlier. So if you already have a proposal just posted in the chat, for example, you've done it for the second. Yes, too many chats. Yeah, so here you may see that there is already a proposal somewhere in this chat. Yeah, that lasted lasted last last message which I oh, yeah, there. Yeah, I don't. Yeah, so you may see that has already started this proposal. And what we recommend you to do is that when you create a proposal, you make sure that it's actually shared with everyone. So that it's public that everybody can comment. Okay, so something like that. It helps other community members to be able to join the discussion to provide feedback. And the same as project ideas. Please make sure that this project proposal is public so that we can review them together and enhance them. Okay. And can I ask about some questions from the plugin? I propose to just finish the process questions. And then yeah, I believe you will have time and we can switch Okay, fine. So any questions? Just go to the details. Okay. So yeah, I think you can just ask the question. Just one second. I was asking about for the cash in validation, we have the item listener, right? Yeah, from the extension points provided in Jenkins core. And I saw the structure of the classes. So job extends item. I mean, job is an item. So can be like whenever any item is created, we could check that if it is an instance of job or not. And then we can modify the cash. Yeah, exactly. So, yeah, all the jobs in Jenkins instances of items. So actually item, there are two types. It's top level item. It's something you can see in the Jenkins web interface. And it's also sub items. For example, if you use multiple branch project, there are sub items as job in instances there. And yeah, but all jobs are items with some extension. What, yeah, if you were talking about promoted bills today, so here you may see that there are tricky things like this promotion. So you may see that promotion is actually abstract build. So it's an instance of run and promotion process is actually an instance of abstract project. So it's an instance of job. So it's an instance of item. But this item doesn't really exist within the three of items within Jenkins. So it's a kind of detached items out of three. So yeah, it's a bit tricky. But yeah, you get this edge case for now. So in your project, you can safely assume that all jobs actually items and they belong to the three. Okay, so there would be some cases which I need to work on. Well, here, as you said, you can just assume that you check whether I can use an instance of job and application. Okay. And another question I think that was unanswered was that having a database like embedding and database into the plugin. So there are two answers. If you want to have in memory database, it's perfectly fine. Yeah. If you want to have a database which persists the data on the disk, then I would rather advise against that for this particular plugin, because once you start persisting data on the disk, you may start getting to the various issues. For example, this backup management with restarts of the instances, etc. So memory thing, it's perfectly fine. So you will be able to recreate it on demand. Okay. So how it usually happens. And I think it may might be useful for other students as well. So when we start talking about static objects in Jenkins, there are two ways. Firstly, you can just implement static variable, which is okay, but static variable can actually persist across Jenkins restarts if they happen within the same JVM. And usually, the advice is to actually bind it to single tons. For example, if you take a whole base authorization strategy, you may see that there is an extension here. Just so yeah, extension. It's distributed implementation. But actually, if you scroll down, yeah, so this quote is a bit latest. Here, you may see that there is an object. So this object is actually a single ton for Jenkins. And here you can create, for example, transient, whatever cache so that it doesn't get persisted on the disk. And it still exists as a single ton object using your Jenkins instance. And when this object is recreated, the cache will be also recreated. So it would be my advice how to handle it. Another doubt that I had here was that whenever the plugin is initialized, let's say after Jenkins restarts or something. A lot of time would be taken to match the regular expressions, weren't it? You mean on the startup? Yeah, when if we consider creating a cache to populate the cache when Jenkins starts up, would it not take a lot of time? So that it might take a lot of time if cache is too really and if it's many items, but there are two ways. Firstly, you can implement the cache in the initializer logic. So it works Jenkins startup while the cache is created. Of course, it's not advised. But you can also initialize the caches in promising. So when Jenkins starts up, you can after all jobs are loaded, you can trigger a parallel thread which would be initializing the cache in the background. And in such case, the performance, the startup time will not be impacted. Okay, yeah, so in such case, you can prevent the performance impact on the startup, but still retain all benefits of caching. Yeah, that makes sense. Okay, yeah, so now I have now been advanced disk order, right? That yeah, so like now, after, you know, to discuss with the mentors and all that, we like I just came to the conclusion that finger printing should be used for the, you know, external workspace manager so that by using finger printing, I can get the workspace ID and from that, I can get the details of the path of workspace and all that and from that details, I can delete the workspace, right? So, yeah, so that's correct. But what I think is that now the builds which are created by the multi branch pipeline plugin or the multi branch pipeline project and like if someone adds multiple work spaces in the Jenkins file, then would the fingerprint work in this plugin also or else it is specific to the external workspace manager only? Well, fingerprints have been attached on the build level. So even if you take and talk about multi branch pipeline, so multi branch pipeline actually is organized relatively simply. So there is an item that there is an item called abstract folder or just Yeah, so and multi branch is actually a computed folder. So it's a folder which has been generated automatically by the background logic. But this folder still contains the common items and these items implement common builds. So it means that fingerprints and all other pipeline logic will behave pretty much similarly in multi branch pipeline. So if everything is implemented correctly, you won't need to implement specific hooks for multi branch pipeline. Okay, yeah, so like, can you just scroll down to page number eight of my proposal? Yeah, yeah, yeah, just a page up. Yeah, so here's the implementation of, you know, of multi branch pipeline. So like what first I what my idea is that first of all, obviously that run listener would be used for the communication between advanced builder and multi branch pipeline. Right. And, and like, now, there are two methods which I finalize, which can be used for trigger that is on finalize and on computer. Now that would be like, I discussed this one with the Martin sir, and he told that we will finalize one method in the community burning period. So like, he just suggested to write both of the method in my proposal. So so I have listed it both. And like, now, so these both the methods will be triggered. And now, for the Jenkins file, now what, like, now the filter methods will be given at the data bound constructor and that and the main class would be extended by the abstract step IMPL. So that methods can be used in Jenkins file. So like user can directly use that methods in the Jenkins file to call that a particular filter and the filter values needed to be specified in that that and after that, the delete method would be implemented, which will fetch the root of the workspace is a pipeline. And from that, by the layer of layer, layer of layer, the filters will be executed. And after that, the actions would be executed. Yeah, it can work. Yeah, I think that this level of details is fine for now. So what you need to do is maybe continue working with mentors to utilize the things. But yeah, from logic description, it looks to be okay. And yeah, we'll be able to define details during the community burning. Yeah, yeah, so like, I just want to confirm that like, this much detail is enough or like, I need to, you know, specify more, you know, a concrete detail which can be useful, like only that was my only doubt because Yeah, so this level of details to bonus this much more than enough. Okay, we expect students to submit something like maybe two to four pages of proposal. So it really depends. So we do not actually judge by pages, we judge by content. Yeah, yeah, I would say that this level of detail is more than enough. But probably, okay, for external review, you may even want to consider somehow breaking it down. So having details in appendix and have related the short description in the body, because it may help potential mentors and reviewers to better understand what is your plan. Does it make sense? Am I still online? Yeah, I guess so. So yeah, proposal is not about a number of pages. If you can write a good proposal with two pages, it's perfect. If you need 15 pages, it's also perfect. But we really recommend to have at least main sections to be short enough so that they can be reviewed really quickly. And then you can put all the details in the additions of your proposal. Okay, do we have any other questions? Pateci, you were pretty silent today. So if you have any questions, let us know. And yes, sorry if I pronounced the name incorrectly. It was correct. Actually, this isn't I don't know, like, it's not related to Jesus. I shared one thing regarding the blue ocean plugin generator. It wasn't working. So I raised an issue and as you suggested, I posted on the mailing list as well. But as such, I couldn't elicit a reply from any one of them. So should I follow up or like some no one is working on that presently? Yeah, I definitely know that the people are working. So they think that last week, almost everybody from the blue ocean team was traveling. So I suspect it just got missed. Unfortunately. So it's somewhere in the mailing list, right? Yeah, it's in the knowledge and kids developer group. It's on GSOC. Yeah, so if it's okay to answer the question, because not everybody from the Jenkins community is in JSOC. So yeah, sorry about that. Yeah, I should have noticed it. Okay. So yeah, if you have generic questions, even if you're a student, it's better to ask the developer mailing list because it has a much bigger exposure. Okay. So here, for example, let's see, the abortion. Generator for abortion pipeline development. Okay. Long game tutorial. Okay. Yes. So here, you should really overfeed the developer's mailing list. And if I recall correctly, there is also no there is no abortion developer mailing list. Yeah, thanks for bringing up this question. I'm sorry. It was me who missed that. Okay. Okay. So thanks should be good enough. And yeah, thanks again for submitting tissues and for working on this area. So from blows from JSOC team, there is Craig Rodriguez, who is one of the mentors. He's particularly interested. So yeah, I think that he might be able to answer. I'm not sure what is that about. Okay. So yeah, if there is no response, please think me I will help to get a process. But yeah, if you have development related questions, something like hardcore, etc. asking in the developer mailing list is probably the best recommendation. Okay. Are they any other questions? I guess no. So yeah, just all we will have two sessions tomorrow. One session is common mentor meeting. Another one is another corner session. And yeah, next week, the application's open. It doesn't change anything specifically for us because we will be still doing business as usual, always meetings. But if you need more feedback from mentors, please don't hesitate to ping them in the charts because everybody is busy, but it's our joint interest to provide feedback to you as a part of the application process so that you can create better proposals and we can, yeah, we can just provide some feedback initially so that when we get to community bonding, we are more ready and that everybody can understand what would be the scope. Okay. So thanks, everybody. And here, I think see you tomorrow. Also, the broadcast.