 Okay, we're live. Welcome everyone. This is the Google Summer of Code office hours for the Jenkins organization on June 26, 2019. And during this meeting we answer questions from mentors and students with regards to the process and the program. Okay, do we have an agenda for today? I don't think we have a specific agenda because this is the meeting in the middle of the evaluation please. We discussed all evaluation plans and expectations at the last meeting and yet today is rather an opportunity for having Kone and whatever unless somebody else wants to add anything specific to the agenda. Okay. I was curious what the feedback was since the presentation yesterday. I saw Jesse's response about he couldn't join live. It's alright. When we did our student presentation yesterday we mentioned that we didn't get any many questions and then I saw Jesse's response saying he wouldn't have been able to meet the meetings anyway. So is our expectation for there be follow-up questions? Well basically there is expectation but again what we did yesterday and what we're doing today is rather a practice session because we give students opportunity to just try out the process and then we will have a real scale demo during the next evaluation please. Thank you. Yeah this approach I suggest to take. Obviously if there are people joining today and if there are questions it would be nice. Usually there are only a few people who ask questions during the demos because most of the stakeholders already had an opportunity to ask questions to participate in project discussions. We still want to use this demo in order to facilitate the discussions and maybe in most of the stakeholders. Okay. Are there any other questions? I saw some questions about the alpha release so I don't know. We had talked about kind of syncing up on this meeting. Should I go ahead with those? Okay. Yes go ahead. Okay. So I had noticed that like the first time I tried that it like released to GitHub but then it wasn't an Artifactory so then I redid it but I don't see like a second release in GitHub. Was I supposed to see one? Let's take a look. So do you see my screen? Let's see. Yes. Plugging installation manager. So we are talking about this project. Basically it applies to all projects where you do any kind of releases. So here what we can see is that there is one release which is referenced as 0.1 alpha 1. So there was only one release recorded to GitHub and we can double check what's inside. So you can see that there is only release and after that you can see that there is preparation to the release as one step and then there is prepare for next development duration as a second step. So it looks like either something went wrong or we relieved from our brain because otherwise these steps should be nearby. Okay. So I should just try to release again then? Yeah basically if you are afraid about any issues so while you are in alpha 3 you can basically do whatever you want and we could try to investigate what's up with this release. We could try fixing that but yeah the best advice is to just burn the release and to have another one on the top of that. So maybe the metadata should be correct. So if you take a look at this project you can see that now it's here 0.1 alpha 2 snapshot. So theoretically it should be released correctly now but yeah you can only try to see what's the result. Okay and then basically the next steps after this are once I get that fixed I just need to include like a change log including like what's actually in that release. Yeah it's a common practice. So regarding change logs we have multiple standard approaches in Jenkins. One is just putting change logs to Viki or to GitHub. So for example one of the common states a bit okay for example we can go to plug-in POM. So here you can see that there is change log as a markdown file. So this is an old approach which has been heavily used in some components. Another even older approach is to just put change logs to Viki but we don't really expect new projects to use Viki heavily. We moved to GitHub and recently we had a new flow for change log generation powered by a release drafter. So if you go here you can see that there are some releases recorded as GitHub releases. For example there are a couple of releases with some references called request etc. And basically this is the flow which has been just announced a couple of weeks ago. It's powered by a tool called a release drafter and this release drafter is basically just a GitHub application which is configured in your repository. Well configured is probably overstatement because all the information has been retrieved from a global configuration provided by the Jenkins project. So you're basically just the right tag templates and you can get your change log generation running. So if you're interested in that so you can just go to .github release drafter auto and here you can see that there is documentation how to use it, how to configure it for your repositories and you can start from there in order to just set up for the first version. I was gonna say I did look a little bit at that yesterday so I don't have like admin rights for my repository right because I think there was a note that if you don't have that you have to like submit a ticket so I just wanted to check like I would probably just have like read or write access right okay. Yeah right so it's one of the ways if you want to save your time so right now there is also another way to just quickly get something so if you if you here go to the releases you can see that there is current form one zero one alpha one basically it's a tag and to protect what you can do you can just see that now it will be a release so something like so you can just write something like that and here you can for example put initial release or something like that and you can just publish the release and it will be also fine for the current stage even before you can be the release drafter so if you want it can just save it for you and basically it will be your first release. Okay thanks. Yeah so if you want to you can just publish it yeah this is a preview release. Yeah it can be published release and the easier first release for this component and then when you create new versions you can get the real change logs you can edit these change logs if needed and the later you can also enable the release drafter so that you get automatic change log for your generation. Okay thanks. Okay. Do we have other questions? Abhudaya do you have questions? Oh no nothing from me. Okay so if there is no questions so yeah in 90 minutes we will have a second part of GSOG DEMOS. Just make sure to prepare to them if you're presenting if you're not presenting you're more than welcome to join in V2 and to watch the projects being completed by the students. Yeah and I guess it will be the last public meeting for the first evaluation. We also ask all mentors say if you haven't submitted your evaluation yet please do it as soon as possible. We have shared change logs sorry google docs for evaluation templates and yeah you can use them. Thanks a lot to all students all students have already submitted the evaluation we are just waiting for a few mentor teams. Okay so if that's all I suggest we adjourn the meeting. Everybody gets more time for coding or practicing their presentation. Thank you everybody. Okay I'm gonna stop the broadcast now. Thank you everyone. Okay thank you.