 Okay, we are live. So, the February 20th is just another weekly JSOC special interest group meeting. Yeah, we had meetings every week and I believe that we had more meetings that all our special interest groups all together. But yeah, we continue organizing them. So yeah, there is no specific agenda for the meeting today. Let's just discuss questions. Let's just discuss action items, the status and the progress. We have one week left until the sector with usations will be announced. So, at the next meeting on Wednesday, we will be either celebrating and coordinating the next communication efforts. Like, yeah, we'll try to stage the blog post or whatever in advance. But yeah, next week we should know the result. And if we don't get accepted, then we will be just doing retrospect if I believe. Yeah, let's see. I'm optimistic about this, yeah. Okay, let me share the screen. Does everybody have access to the meeting notes document? Do you see my screen? Yes. Yeah. Okay. That's all. Let's see what we have. We have a bunch of action items on me. And yeah, I can just say in bulk that I haven't actually implemented anything because I was completely snowed under Java 11 Volubility. But yeah, I will make sure that I will follow up on all action items before the weekend. So all these action items are still on me. And yeah, regarding our team for Jenkins REST, it's done. Artifactory hasn't been actually done. Artifactory. Artifactory, I pushed it moved to draft and I created a pull request to move it to the published state. Oh, yeah. I think yesterday. Yeah, let's probably take a look while we're around. Okay. So it's Artifactory. Okay. So yeah, we have text. We have discussions. And yeah, I believe that all comments from Jesse have been integrated here, right? Yes. So if there is no objections, I would just post it. So we have quick start guide. We don't have new befriending issues for this project if I understand correctly. But yeah. That's correct. Yeah. I think that it should be okay to publish it. Jeff, what do you think? I agree. Okay. Then we can just do the draft. Yeah. It should be fine. Okay. Then we have a more published project. Okay. Yeah. Thank you, Martin, for that. All right. So now it's done. Then yeah, we had advanced discard field step sync up. It was on Monday, right? It was on, yeah, it was on Monday. Mm-hmm. Okay. So yeah, this is good. And you believe that everything is fine. Are there any meeting cards for this sync up, by the way? No, there's no meeting notes. It was more, no, there's no meeting notes. And no recording, right? And no recording because I couldn't do it. So I have to learn about, I have to learn how to do recordings properly. Okay. I'd like to do a PT with Martin, probably Evelina and whomever wants to join. Evelina also had an issue with that. Even though it's resolved, I'll send a message. So let's try to do it next Monday, for example. Okay. Yeah. Okay. Yeah. And they'll just copy all my action items from here, I believe. Sounds like I should start doing something. Okay. We took PT with Martin, we did, et cetera. Yeah. That's okay. Probably I will just do a PT tomorrow as a part of advocacy and outreach sync meeting. Oh, yeah, of course, if you do the same type, I'll try to attend. Yeah. I just need a agenda for the meeting. Maybe I will address that. If not, I will run a separate meeting. It's on the morning in Europe. So probably it's not comfortable for you, Martin. Okay. Okay. What time in the morning? 8 AM UTC. Okay. No, that's too early. Well, it's too early even for me. Okay. Yeah. So what else do we have? Documentation, a plugin. It was also published, I believe. So we have only two projects left. One is Jenkins and the machine learning thing. And another one is freestyle job to pipeline job converter, which is on Craig. But yeah, I believe that it hangs because, well, yeah, Craig, I didn't have a chance to address comments. Okay. So I will try to reach out to him or maybe somebody else. Yeah, I'm not sure. Is anybody specifically interested in this project? Can you repeat the project name, Oleg? Freestyle project hangers to pipeline job. I would be interested in this depending on how it's implemented. I have cases of freestyle jobs that I'd be happy to convert to pipeline. Interesting. Yeah. So I'll just park it as this. But yeah, somebody needs to pick Craig. Okay. I can ping him. I think he hangs out in the pipeline authoring thing. Yeah. He's actually pretty active in the Jenkins community nowadays. Yeah. So yeah, it shouldn't be a big problem. I'm just trying to be paralyzed and yeah, I will appreciate help. Okay. So I believe so the last project is machine learning. But yeah, Martin is off till 22nd of February, if I recall correctly. Yeah. So I believe that we shouldn't be touching this project. It got some feedback and it also got one potential mentor. So I will process the mentor part, but for the rest, we really need Martin. Another Martin. Yeah. I think that we will be able to publish it soon. Preferably shortly after the GSOP organizations announced. Okay. And yeah, I believe that's it. So we could just focus on questions then. If there is no other topics to discuss. And a time for questions. Yeah. I think we can just talk about any questions you may have. And yeah, then if you have some time left, we can do other organizations stuff. Like I was interested in the external workspace management and plugins. And I was wondering if I should start doing some specific or concrete job right now. I noticed that if there is an item in the external workspace manager, a concern with good design plugins. Yeah. That is what a design is interested in. So if there any chance we can like discuss how to augment as a code base, how to start with the actual work. Or is it just still preparation for the final project idea. So you're interested to understand how Jinx organization works, right? Well, how Jinx would be organized. No, I just want to discuss with like my potential mentors. How do I organize like doing cloud cloud feature for the for one service provider like the EFS. Yeah. So, Martin, would you be interested to answer this question? I can try, but it's hard for me. I've never worked with the cloud provider. So I don't know how like on the implementation side, it would work. I can only answer in generalities, you know, such as use extension points and study the code base. Fortunately. If it's okay to discuss with me, I would like to like first write a draft idea of how I'm going to plan the organizations. How do I organize a code base? I think it's doable. Yeah, maybe in the next few weeks. I just come back from application and it's like it's like six in the morning. I really had a hard time getting up early. That's understandable. So if needed, we will be scheduling other meetings and other time zones. So it's okay. Yeah. Are you based on the West Coast? Yeah, I'm in the West Coast. Thank you. Yeah. So we have Jeff and Lloyd, but yeah, the early risers. So for them, it's not a problem. But if needed, we will split our meetings so that we can offer better coverage for this region. Yeah. Regarding the project itself, Marstein is totally right. So all kinds of Jenkins. So the main idea of Jenkins is that it's automation framework. And it's fully based on extension points in terms of the implementation. And external workspace manager already has some extension points. So for example, your extension points Jenkins. At some point I will remember the link. Yeah. So yeah, so there is a list of extension points for all Jenkins plugins and the core and there is external workspace manager. So I'll just put the link to the meeting nodes. But yeah, you may see that there are two extension points. One disk info provider, which provides disk status, et cetera, and also disk location strategy, which implements the logic of selection, the disks and workspace from multiple options. But what it doesn't do today is effectively providing the disk. So for example, getting data from EFS, et cetera. So my understanding that there would be a new extension point here, which allows to define source of the provisioning. Now there is only file system provisioning the factor, but we could create a new extension point, which would allow it to somehow customize that. And it would be a starting point. And after that, yeah, we can provide some reference implementations. And of course, having EFS as a reference implementation would be something really interesting. Yeah. Actually, there are maybe there should be four extension points. Like I have mentioned before, there's like it needs to support the beauty scar plugins and it's not supported in the current version of external workspace manager. Yeah. Maybe I have to work as a Nassar, right? Yeah, I'm listening. So yeah, I think also the problem mentioned that the builds which are in the external workspace are not being discarded. So I think that can be integrated with the external workspace manager plugin. And I think if you do work together, it would get approved. Yeah. Also, like some monitoring issues. Yeah. So just to provide you some hints guys. Yeah, these projects are related to each other, but it's not that like one project blocks another because it's kind of build steps plugin operates with Jenkins core APIs. And Jenkins core API invokes, for example, removal of builds. So yeah, I don't have Jenkins instance which I can show or probably use one of instances. So yeah, it's probably not the best example but okay. So here if you go to the build history, you can delete a build here if you log in. And when you delete a build Jenkins calls extension points for cleaning up of the dating, including clean up workspaces. So just for clean up future, how it would be happening, discardable steps will be discarding the build and then Jenkins will be invoking its own extension points to actually remove the data related to this build. And you will see from the top of this extension point to free external workspaces. Or you can use fingerprints engine to trace usage of workspaces and then you will be able to do it as well. So yeah, I believe we could have a codef about that. I'm not sure what would be the best time frame. Okay, so I just want to say one thing that if we can have one KT through which we can understand the working of external workspaces and how the builds which are not discarded through that can be understood in a more preferable way with the mentors and the students interested in that. Sorry, I didn't quite get it. Could you please take it? Yeah, sure. So I'm just asking for a KT through which the working of the current external workspaces can be understood in a more better way. And we can know that how the Jenkins core API can be integrated with that and how the build discards can be done through the external workspace manager. Because as you mentioned, we know that builds which are not discarded in the external workspace should be linked with this plugin. So I think that if some more knowledge we can get of that plugin and the working and also the implementation. There is a raw selector plugin integrated with experience manager. Yes, yes, yes. So the run selector plugin actually filters the builds of the some logic but the builds which are not discarded in the external workspace manager. I think that could be solved along with that plugin only. Well, it's hard to say for sure because how I would see build discarder plugin. Let me show you. There is built to discarder extension point. It actually in one of the logics. So in Jenkins UI, you can see that discard all builds. And with that you can select various strategies and there is a number of strategies available right now. For example, Jenkins core, built rotator, etc. And my understanding that advanced build discarder would be one of the options here. And it would be offering some additional logic as discussed in the project idea and as described in your proposal, but it's one of the options. And finally, all these discarded logic. So if we take a look at the Java doc. One purpose of this extension point is to actually perform garbage collection. So you invoke that and it executes a task against job. So it decides which builds to delicate and then executes on that. And your implementation will be invoking standard methods. For example, let's take run, I believe. So in a run, there should be a method for deletion. At least, yeah, run delete. And this run delete method, effectively when it executes, it will be invoking other extension points, etc. So for example, you in build discarded plugin finally end up here invoking deletion. And then the plugin, for example, external workspace manager, it will receive a message that the build is being discarded. And then this plugin will be able to just go and delete work spaces if it's configured. And yeah, that would be the integration. So that external workspace manager plugin would just show the message that these builds are being discarded and then the plugin which will be implemented or a new plugin which will be introduced through an extension point. That would go and just call the method and it would just delete the builds, right? Yeah, something like that. Yeah, okay. So I think in external workspace manager plugin, also some codebase needs to be understand because at which level the method should be called, I think that should be known, right? Well, external workspace manager. Yeah, I'm not sure whether I recall the code correctly. This was a while ago for me. So here what it does, there is already some implementation details and if I recall correctly, it already has listeners for automatically discarded the data or not. Martin, do you remember the code? Which part? Which part maybe I have? So after completion of the job, it may delicate the workspace. You may delete the workspace. Just a second, let's take a look. Maybe I messed up other things. Let's take a look. So what we have? We have facets. So effectively we have some metadata attached to fingerprints and let's take a look whether there is logic for deletion. Workspace, browser, protection. So it just allows browsing the workspace there. But you're probably right that there is no method for deletion. There is an example of workspace cleanup. So here you may see that actually they implement cleanup using another plugin, workspace cleanup plugin. But it's not something we would like in terms of these two stories because what would it be that workspace manager will be receiving external call. It will be checking the built-in metadata and cleaning up the workspace and so on. So yeah, you're right. The logic is not implemented in the plugin. Yeah, it's like the external workspace I think we can finally use by different views and different projects. So I haven't seen anything related to deletion in workspace yet. So it's relatively simple to implement, I believe. Yeah, you don't agree. Yeah, but yeah, this is the logic which we will need to create. It's a good addition to the plugin. So run listener Jenkins. There is extension point run listener. And this extension point effectively has, yeah, it has method like on deleted. So effectively you will be just creating extension point implementation and subscribing to these events. At least, well, if it works. But yeah, I believe it's how it would look like. So effectively discard build step plugin or whatever will be invoking run delete method. And then it will be ending up in this endpoint location for the listener. And hence you will be able to follow up an external workspace manager and clean up workspaces if it's needed. Okay. Does that make sense? Yeah. So obviously there may be different details once we get to that. But yeah, I believe that to start the investigation it should be helpful informations of it. You can experiment a bit with existing extension points and implementations. So yeah, if you need anything else for the proposal just let us know. I've got a question. So on Monday we were presented let me see if I can share this link. We were presented this file. I'm going to paste it in the chat. And maybe I should share my screen. Okay. So if this is a user and this user has prepared this example for us. Somebody's microphone is rubbing and it's making lots of noise. Okay, so. There he is. Okay. Thank you. And so if you have any questions or if you have any questions please let us know. Okay. Thank you. And so if you scroll down. So the idea here for. Sorry, I should start at the top. Okay. There's multiple stages. And the way this user imagines that the. Advanced build this car would work. And the default configuration for the build this car. So on five or some default. And then the user would prepare some filters on line eight and nine. Yeah. And so he would create these filters and give them specific names. Obviously the example is written with log rotator, but. Yeah. So it would be something like that. And once. So for example. So that one filters to something like that. Right. Okay. I'm not. Okay, some filters. And then these filters would be activated. Later. In the different stages. Oh, that's interesting. It is interesting. That's why I want to show it. And. So depending on how. Far along. The build. The pipeline. Progresses. Into the different stages. These builds have to be retained. The retention criteria for the build. Changes. Yeah. Why don't you go ahead. Yeah. Why don't we integrate it with. Another plugin. For example, if you take milestone plugin, they could say that it's for. Miles. One. Something like that. And here there is. It may look a bit weird. I don't recall the correct syntax or whatever. There is a milestone plugin for pipeline. So maybe something like that. So what it means that. Yeah. When it reaches milestone one, this filter is activated. Stone plugin. Thank you. It's even easier. So it's not for declarative pipeline. I'm not sure what would be syntax for declarative. Maybe we could ask Andrea about that. But yeah, we could just. See that it's something like that. What you could do. If you just need declarative behavior with limited functionality, you could do something like that. So you can enable filter or when it reaches a particular milestone. So here, for example, it would be discard enabled only for this stage because we pass a milestone for this stage. And after that, the filter is enabled. We talked about the milestone filter and the milestone. And I thought the milestone would decide the fate of a paused build. Whereas the build discarder decides the fate of completed builds. Well, it built may complete, but it may fail. So, for example, it may fail on build sources and it will never complete this phase. And it means that it will never complete the milestone one. Right. However, the default filter is five days or five builds as shown on the line at the top. So the default discard, I guess not filter, but there's two things with build discarder. There's conditions for discarding a build and and I and filters. So the condition might be five days, but the filter is how many days has it been? Has it been five already? So there's a difference between the filter and the condition, the filter tests for the condition. So the condition is not the filter in my mind. Well, it's an implementation detail. So, technically, you can implement anything and it would be a metaphor mentors and for the student to define what is actually going to be implemented. Because engines can be implemented either way. It just depends on what you actually need. Right. Now, could you scroll down to maybe line 40 or 50? There's another thing here. For example, on line 63. Now the build has been deployed to production and in this case the user says that when you reach production the build should never be discarded. It should stay in Jenkins forever. That's the user criteria. Yeah, but for this stage we already have such logic in Jenkins. In Jenkins, you can actually just mark the builds as key forever and they will be kept forever. So for this particular case, yeah, probably it was just an example, but for that there is no such pipeline method. You can ultimately implement this method and use existing Jenkins APIs. Interesting. So for example line 42. Line 42 is we've reached quality assurance stage and so the condition for discarding this particular build would be is the one that is shown on line 7 near the top. I don't know, maybe it's keep for 10 days or something. Yeah, 30 days I think I saw. So yeah, I think it makes sense to take a look at this project but you can implement whatever you need in Jenkins. It might be more difficult or less difficult depending of what you want because if you need some stateful logic then it becomes a bit more complicated because you need to inject actions into the build but it's something doable. If you just want metadata like something like that it will likely be an action or fingerprint as well but it would be a bit easier. Okay, so maybe it's easier than maybe it's easier than I thought it would be. If there's if there's a possibility of creating a call to the keep build forever we could have a call to keep build for a number of days. So keep for a number of days it would be definitely a advanced build discarded plugin. So keep forever is just a functionality which is already available in Jenkins but there is no equal functionality but keep for five days. So there is a log rotator but it doesn't work in such way so you would need to somehow define a flag that this filter is applied. You would need to somehow save this flag to build XML so that it's persisted over restarts and Jenkins remembers that and then when there is advanced discarded plugin invoked it checks these flags for historical builds and makes decisions. So it's totally possible it will be a stateful logic but it's something you can do in Jenkins. So for example external workspace manager plugin it's also stateful because it attaches finger prints to track workspace usages in jobs but it uses finger prints for that. But are you suggesting that build discarded should also use finger printing? Not necessarily. It can be either finger prints or run actions. Well probably it's not the best link but yeah let's see. Yeah run actions actually deprecated because they are just replaced by action. So yeah the idea of Jenkins that there are actionable objects and actionable objects can persist the data. For example yeah this is action for example all standard implementations like run it's build or for example queue item it's queue data, abstract item it's jobs and folders also computers they may have metadata stored in actions and this interface allows to persist the actions if needed or to get them dynamically but if you persist the action in the object you can use this interface to retrieve the data. So action interface is used in Jenkins widely. For example if we just take pipeline integration we have Jenkins CI there is a metadata class called run action tool. So yeah 94 usages and all these usages and yeah it starts from external workspace manager plugin due to whatever reason yeah it means that the data is persisted on the disk there and it's persisted specifically for pipeline because run action tool was developed specifically for pipeline. So yeah you can take a lot of existing implementations. Fingerprints is another engine which is a bit less popular because yeah it ties to artifacts it doesn't build the IDs though yeah there are plugins which just considered built as an artifact but yeah all the usability happens there on the global level. So fingerprint applies to multiple jobs and multiple runs but run action applies only to a single run. So depending of what you want you can select different ways to persist the data. Is that okay with you Martin? Yeah yeah thank you this is this is good to know yeah. Okay so yeah rule of thumb you start from actions actions are not enough for your use keys you can see the fingerprints. Okay. Yes thank you. Yeah happy to help Are there any other questions? Will we around? No for me I have all my questions No not now right I'm not now Okay Yeah so I think we can just we have 10 minutes left so if anybody is interested to discuss anything during this 10 minutes let's do that or actually what I wanted to do if there is no other questions is to take a look at the student guides because if you have anything about the existing guidelines it's something we would appreciate So they'll just Yeah so since you already get some experience projects GSOC students Yeah So I have one doubt Oleg that I have read in the GSOC documentation that some organizations have a limit of a project that your your draft or your proposal should not exceed some words so is there any restriction with these 10 kids organization that our like our proposal should not exceed some words or some basis like that Yeah so the idea of the project ideas we have here these are project ideas so it means that the objective of all these descriptions is to give you an idea how the project would look like some project expectation of what students communicate in the applications so for example for external work space manager it's reasonable to expect that a student who submits a project idea there comes up with proposal what would be the reference implementations and same in other places so all these project ideas are just project ideas if you take this project idea and submit it as a part of your application most likely it won't work well Yeah okay okay so like there is no restriction in words or in the number of pages of all the words right so like it can be 7 to 8 pages long too right because like I am planning to you know put a flowchart or some steps like how will I approach to the problem and how my implementation like how I am planning to implement this so like it will take some more pages Yeah so JSOC application isn't about pages specifically you may have a good project idea in one page or in two page or you may have 10 pages so there are guidelines defined by Oracle which also provides some advice what has to be in the project idea not in the project idea in the project proposal Yeah so what yeah mentors students information for students so here do you have a specific section for project proposals application steps and draft your own proposal yeah so there is a student guide JSOC student guide so it is the good source information of that and yeah there is writing a proposal what is expected and actually this is what you would expect so what you should focus on when you create a proposal just to explain what exactly you want to deliver in your project this is important of course it's important to think about how it will benefit the community in some cases it depends on what you propose so some project ideas here are pretty straightforward some are not and yeah it's it depends but it would be still an expectation we need to understand that you understand how it fits the Jenkins organization and what value it brings to the community and to Jenkins users so it would be a part of that and yeah then yeah this is actually what whatever you do so if you have some ideas how it would be designed what would be the architecture please put it to the proposal it's helpful if you have some ideas how to test it how you would design for example web UIS it's also important you can just put everything there and all this information contributes to the proposal any original idea any original approach which would be helpful okay Martin, Jeff would you like to add something yeah this is good another thing is that I've noticed when student prepare proposal is that they have examples for each coding period I think there's three coding periods and so it's important that the student scopes attempts to scope the work for the different coding periods and of course it can be adjusted as we go but it's important for the student so you can take examples from previous years I believe it's linked somewhere from here or not maybe it's not longer linked, yeah project proposal so it's Cheng Yu, he's a mentor this year but yeah last year he was doing a JSOC project for core coverage API plugin so I just opened the example and it includes some information from what would look like, how it would be organized etc so one of the ways many applications including Jenkins publish project ideas and applications from the previous year because our advice is when you create a project idea you keep it public so that mentors can review that others can review that and you can communicate it to the community so he's an example of proposal it was a successful proposal it was accepted, the project was completed and you may see that there is some timeline it is deliverable yeah and we just stopped putting statuses at some point because the project was completed but all these deliverables have been delivered and you may see that deliverables is not just the plugin release per se it still has various designs various features to be put so some fine-grained targets would be nice and yeah something like test automation documentation is also deliverable especially if you describe them in your proposal so this is what you need to take in mind and in Jenkins organization we set a requirement that all test automation that all project have some documentation because we want the project results to be used hence we set expectations for that yeah, okay, thank you all for the information I hope it helps if we get accepted I think that next week we can take a look together the proposals and maybe record a special guideline for that yeah, it will be much more helpful to us for adding our proposal okay so the proposals recording session about proposals applications yeah, I think it would be nice to have this or generally we can just if the current recording is good enough we can just post it okay, anything else? I'll stop screen shank any other topics? We have two minutes before the meeting ends I don't have anything okay, then I guess thanks everybody and see you in Gitter yeah, it's the last weekend before the hot part starts we'll get accepted of course and stay tuned thank you all