 Okay, it should be recorded now. Hi everyone, thanks for joining us on the Meetup. Today we have a number of presentations by Jenkins summer project students. We had three projects this year. It's a Google summer of code outreach and community bridge. As I said, this is the third part of the demos. If you are interested to find previous parts, you can go to Jenkins online Meetup. So you can find two post meetups a day. We had seven demos in total and you can find all recordings and links to slides there. Today we will have a third part where we have two presenters from Google summer of code and one presenter from our teaching. I'll spend a few minutes in order to introduce these programs if you don't mind. The previous Meetup market has already done a great introduction to Google summer of code. So I'll be quick. Yeah, Google summer of code is just one of the biggest open source programs in the world. It has thousands of students and for example this year there were almost 200 open source organizations participating and the Jenkins project is proud to participate in this program. This is our third year in Google summer of code. Basically the program started in March and the results have been announced just a few days ago. So we have seven projects this year, five projects have successfully graduated. So they passed all the evaluations and you can find blog posts, these results summaries on the Jenkins site or website. All these projects have been presented in the previous demos. If you have any questions about Google summer of code, you can join our Twitter chat. And that's the quick introduction. Regarding Outreach, we haven't introduced it yet in our meetings but we have Tracy Miranda on the call. Tracy is the leader of Outreach in Jenkins. Tracy, if you want to say a few words about that ratio, it would be great. Yes, great. Thanks Oleg. Jenkins in Outreach. If you may or may not know, I am the Jenkins Outreach coordinator. I work with folks like Matt to identify the projects and set and find mentors and then we go through the application process. Jenkins has been doing Outreach for the last two sessions. So we started back in 2018. And I'm happy to say up to now we've had four students who have worked on Jenkins to in each round through the Outreach program. And specifically they've all been working on the audit blog plugin. And one of the things I wanted to say is that it's been really great kind of participating in this project. Well, the program, so first of all, because Jenkins participates in GSOC, we've been able to benefit from all that knowledge about the internships and move that over to Outreach. I think specifically for me, Outreach has been really good in also highlighting other things like we get a lot from the Outreach community thinking about, you know, how do we communicate with people who might have imposter syndrome? How do we change our language a bit? So that's been, you know, pretty eye-opening certainly from my perspective. And as ever, it's always nice to welcome new people into the community. And one thing I just wanted to add as well is what I'm really happy to see is what we've learned in Outreach. We're also taking to the other open-source communities and under the CD Foundation, Continuous Delivery Foundation. Jenkins is leading the way there now to encourage other communities like Tecton and JenkinsX to spin up their own Outreach programs. So I really like this kind of cross-collaboration that's going on and we're sort of all learning and pushing things forward together. But yeah, just back to today, I'm really excited to see these updates and just sort of see what everybody's been working on. And maybe at the end we can see a bit more about the next round of Outreach coming up as well. Yeah, thank you, Tracey. So I lost the focus. Yes, for both programs, for Google Summer of Code and Outreach, we are looking for more contributors. For example, Outreach starts soon. There will be another winter round and in Jenkins project we are interested to apply. So we are looking for project ideas for mentors and technical advisors. And of course we are looking for students. Same for Google Summer of Code. If you're interested, we will definitely participate next year. Well, my fingers crossed that Google Summer of Code will happen and if so, we will definitely apply. So if you have any project idea in mind, if you have some issues with Jenkins, if you need a plugin which is missing, and if you're willing to invest some time to become a mentor, we will welcome you in Jenkins community. Same for students. If you want to join, there is a lot of opportunities. And it's not only about long programs. We also have other programs. For example, on October 1st, we will have Hacktoberfest. So Hacktoberfest is a worldwide program. Basically, it's an online habit on where everybody can contribute to open source projects and get some swag in return. In the Jenkins project, we also invite people to contribute. So if you can see the join in JSoc, Outreach, maybe it's the best opportunity to explore the project. And yeah, for example, in 2018, we had a blog post which you can refer to. There will be a similar blog post for 2019, once we go live. But what we're mentioning there was it's not something like we just submit to Hacktoberfest and wait for contributions. We actually prepare projects so that newcomer contributors can join the project easily. So you can see that we have a number of select projects. So this is at least for 2017. We will have similar at least for 2019. And for each project, we have contributing guidelines, we have newbie friendly issues. And we also have code reviewers for on standby mode and who are ready to review your contributions. So we try to reduce the feedback loop as soon as possible and we try to help contributors. And we invite everybody to participate in Hacktoberfest and other activities. So if you're interested, it just starts next month. And hopefully we will also have some local Jenkins area meetups. So it's just on site events, which I'll say part of Hacktoberfest. So stay tuned for announcements. Okay, back to the today's agenda. We have three presentations today. We made some changes to our schedule. So first presentation will be from Amir Day about my management and framework for Jenkins plugins. Amir Day already did a presentation about role strategy, plugin performance improvements, but he has much more to show. So thanks a lot for joining us again and doing a new demo. We also have Artie and Gayatri from Outreach who will present audit work plugin. And we have this speaker from my CVCRAM project. So CVCRAM is another project which was working on a Google summer report. And there was a project for beta study code analysis in Jenkins pipelines. So we are happy to welcome other organization and thanks a lot for your contributions. So we'll see some key studies. So before we proceed to presentations, if you have any questions, feel free to use Zoom chat. So you can just ask any questions there and we will ask presenters after the talks. And also feel free to join our Gitter chat so that you can ask questions offline. And then we will try to answer them as well. Okay, any questions before we continue with demos? Any comments? Okay, then let's start with the first presentation. Are you ready? Yeah, I'll share my screen. Can you see my screen? Yes, we can. Okay. So hi everyone, I'm Apyudhe and I created the benchmarking framework for Jenkins plugins during my Google summer of code project. So what we do is we run Java microbenchmark harness benchmarks in Jenkins plugins. So what is Java microbenchmark harness? So it is an open JDK project and it runs the benchmark code multiple times. It does form up iterations so that the byte code, the code, the benchmark code gets combined to byte code to avoid wasting any time. And it provides various measurement tools like to get the average time and the throughput of that is a number of executions that are happening in a given time period. And we run benchmarks on multiple folks to avoid the measurement errors. So we introduced the benchmarking framework for Jenkins plugins. So what this enables you to do is to start benchmarks using Jenkins and it's available to everyone through Jenkins test harness. We have an even profile in the plugin form so you can run benchmarks locally. And we also have a pipeline step in the Jenkins pipeline library for running pull request builds on CI Jenkins IO. We also support using configuration as code for setting up the instance that is started for benchmarks. So the framework works by running the benchmarks directly from the unit test and the benchmark classes are automatically found when they're annotated by JMH benchmark and a temporary instance for every folk of the benchmark is started. So this is what the typical benchmark looks like. So we have a class that is annotated by JMH benchmark for it to be automatically detected and this extends the JMH benchmark state which provides the setup and teardown method. You can override them to set up the folks for your instance for benchmark. And you have a benchmark code that is annotated by benchmark. So you can write a benchmark code here. We can also configure Jenkins configuration as code. You can provide YAML files and the configuration would be loaded and the Jenkins instance would be started for that. We do not yet support configuring the benchmark instances with local data. That is your config.xml files. There is a G-Rot ticket for that so you can follow that. Now when we use configuration as code, we have to extend the cast JMH benchmark state instead of just the JMH benchmark state and you have to provide the path to a YAML file. This also provides you the setup and teardown methods which you can override if you need to set up anything else and you need to return the enclosing class which is annotated by JMH benchmark. And your benchmark code goes here just like it was previously. So the benchmark reports are generated through the unit test that runs the benchmarks and you can measure multiple times through a single run. For more details, you can see the samples on the JMH website. The reports we use are written to the disk after the benchmark completes in JSON and these JSON reports can be directly fed into the JMH report plugin or to the JMH visualizer website. So this is what a benchmark visualized looks like through JMH visualizer. This was the performance improvement in the strategy plugin and you can see the pull request for more information about it. So under the hood, we basically start with the framework that starts a temporary Jenkins instance inside Jenkins Test Harness and we have a Maven profile in PluginPerm version 3.46 and you can run benchmarks locally through that. Then we have configuration as code plugin which uses, which sets up the instance using configuration as code and all of these were integrated into the Role Strategy plugin and the new folder authorization plugin. So we have benchmarks there and these benchmarks run as a part of the continuous integration pipeline and there were performance improvements to the Role Strategy plugin and this framework was really useful there. The reports were generated using the run benchmark step in the Jenkins pipeline library. There were some bugs and challenges that I faced. The first one was Desk from issuer from Jenkins Test Harness was refused to be marshaled. The other thing was Jetty that was running the Jenkins instance but Desk would leave a straight thread running after the server was stopped. So this caused the JMH benchmarks to wait 30 seconds for every fork of the JVM after which it was forcefully killed. There were other issues like version conflicts with Guava and these were fixed in Jenkins Test Harness 2.51. So if you want to contribute, before that I'll just show you how to run the benchmarks locally. So we have a benchmark runner here. This allows you to set up how to run the benchmark and we specify that we want the result in JSON and the name of the output file. So after that we find the benchmarks automatically and we just run the benchmarks. So right now we are just running this benchmark which measures the time for generating ACL objects. This is specific to the Role Strategy plugin. So in this particular example, since authentication for Jenkins is limited to one thread, we set up the authentication for every thread that is started. Now let's just run a benchmark. So you can run the benchmark by giving the dash D benchmark flag to Maven Test and the benchmark run starts. So this is the configuration that is being passed to the benchmark. And after the benchmark completes, we get a JSON report here. So this is what the report looks like and we can just switch to GMH visualizer for seeing the actual comparisons of performance tests. So these are the performance improvements that were made to the Role Strategy plugin. After the improvements we observed were up to 10,000%. And in this particular case, the benchmarks helped us a lot. We also have a blog post that you can read. Yeah, so we have a blog post and you can just, if you want to learn more about the framework, you can read through this. And I would love to hear your feedback and you can contact me through the Role Strategy plugin or through Jenkins developers mailing list. And I would love to have you contribute to the framework that is available in the Jenkins Test Harness. Before I end, I'd like to thank my great mentors, Oleg, Runjian, Supun. And thank you, everybody. Thank you for the presentation. Are there any questions? I don't have a question, but I do have a compliment and that is on your slides. A bunch of us have been noting how beautiful your slide deck is. Thank you. And I would say that it's not only about the slide deck because the content is really great. So we had just provided some context. It wasn't a full Google Summer of Code project. Actually, what Abiodic presented there was just a part of the first coding phase. So before we started doing the performance improvements in the plugin, we needed a way to estimate the impact. So that's why the project started from the performance management framework. And the first implementation was just completed in a week or so. And basically, for the rest of the first coding phase, we were spending time on examples and on improving the performance of the plugin and also on utilizing the changes. Because this framework is not a standalone project. It was integrated into Jenkins components. So it's a standard Jenkins test harness. It's a framework which is used by almost every Jenkins plugin to do a test automation for the period testing and integration testing. Then it was integrated into plugin phones. It was integrated into Jenkins pipeline library. So if you see Jenkins IOR to run test automation, basically, you can just invoke a step and you will get it running for your plugin. And in addition to that, we did some integrations with the configuration score so that the quality of life for maintainers became much better thanks to these improvements. So yeah, it was a really, really great change. And thanks a lot of you there for working on this project. Yeah, thank you. I forgot to add that this framework has now been integrated into Jenkins Core. So all the test cases inside Jenkins Core can use it now. Yeah. My secret was on the call. He actually tried using it in the very beginning. But it didn't work. So maybe they did some other contributions to make it happen. Well, yeah, I was able to get it to work is just that the thing that I was trying to benchmark turned out to not be the issue. In fact, the benchmark helped me discover that the hypothesis that various people were putting inside the Jenkins ticket that I was looking into were completely and utterly wrong based on the JMH test that was showing me that that code path was taking, like, less than a microsecond or less than a millisecond. One of the two. But basically, it was definitely trivial. But it helped me figure out the right thing as well. And this was also tested on Jenkins Core, which made it a little more complicated to integrate. But from a plug-in perspective, it worked. It just worked already, which was nice. Thanks for the clarification. And I have used JMH and other projects before. So I was able to at least jump in and I was happy to see how easy it was to integrate straight from the work that you've done. I can't remember how to say your name. Yeah, thank you. It's a beauty. A beauty? Yeah. Okay. Okay. Yeah, it was a cool project, cool presentation. Thanks for showing us. Thank you. And we invite all contributors and plug-in maintenance to start doing performance test automation. Because if you take a look at Jenkins Jira ticket, there is now a hosting request from James Nord for hosting slow Jenkins plug-in or something like that, which basically deliberately slows down some operations in Jenkins. Yeah. If you use benchmarking frameworks, we can avoid the same behavior in production plugins and we really encourage you to do that. Oh, and I'd like to add, there's no better way to end an argument about performance than by measuring it. So this is a very, very useful plug-in to have. So thank you for that. Thank you. So any additional notes or questions before we move on? I guess not. So let's proceed to the next presentation. Arthi, are you ready? Is on video. Shall I start? Yes. You can just share your screen once you're ready. Hello, everyone. First of all, I'd like to thank everyone who called. It's a great pleasure to have worked with Matt, Jeff, Tracy and other mentors in the project so far. Since we have many new people in the school, I would like to give a description about the project. The project which we worked on is audit log plug-in. Audit log plug-in as a Jenkins plug-in, which is used to audit the events that are happening in Jenkins environment for auditing purpose. For auditing, we have used Apache log 4G audit. As I would like to say Matt, our mentor, has released the plug-in at its version 1.0 two days ago. And of course, as we learned that now how awesome it is to contribute to open sources, still, there will be many more contributions in future, I hope so. And to my knowledge, I would like to say there are two upcoming things in the plug-in I would like to share, which will soon be pushed into the world. One first one is like, which is to define the audit events by API. That I had some hands-on and the other one was like, using a descriptor and describe the classes and getting the configuration of the plug-in at its place. Just before explaining them, I would like to share a short demo of the plug-in. As the plug-in has been released earlier, it can be installed at any Jenkins environment given that the version is satisfied. Now, I would like to say the plug-in is available in the plug-in strength in the I.O. I'll show the installing the plug-in. Since I have already, in my local, I have already installed the plug-in, local setup already, I have installed the plug-in, I would like to continue with it. Once the plug-in has been installed, the audit laws will be shown in the, audit laws will be shown in the field in the audit laws. It shows that the audit laws are in a HTML format. I have to mention that Gayathri has worked on this picture. She gets the log written to a rolling file in an HTML layout and exports the file. And also importantly, administrators will be able to check the audit information in the plug-in. Let me now create a new item and we are auditing the creation, updation and deletion of the items. Whatever the actions, whichever we are doing like creating deletion, everything will be audited. I am creating an item named Hello. As we have created an item, you can see now that it is being audited in the audit log screen. Related to this plug-in, two things are significant. I would like to say that one is list of events that are audited and how extensive it is. And the other is the places where they are audited. This is what I would like to say. And for now, we saw a web UI of the auditor information how the auditing has been happening. Now I would like to say coming to the list of events that are being audited. I would like to say, I remember a few, I would share it. Use your login and log out. Key or password update. Create user. Build start. Build finish. Create copy delet items. And create update delet nodes. And using of credentials. And coming to the events extensibility part, it is currently working in progress. And we are looking things around dynamic audit events and similar things. We would like to say if any ideas or positions from your end is almost welcome. Most welcome from your side. We share them in the outreach channel. And coming to the second part, the places where the audit information is sent to are stored. Once the HTML web UI, one is HTML web UI, we check that now as I have shown you, how it is happening. Next I would like to share usual rolling log files or in some cases, setting the log files to some other services. This part is configurable according to the setup and its requirements in the different organizations. Let's see how to configure them. In manage, in manage Jenkins, go to configure systems. And we have to in audit log configuration, we have to go to we can select which app and I we require to use to get the audit logs. The app and I type either it will be JSON layout or a syslog layout. Now it is configured actually now it is configured to be stored in the audit log file. The file by default it will be present in the logs folder in the Jenkins home directory. Another available configuration is sent the audit logs to another server over the TCP protocol via syslog app. Once it is once the configuration is done, it will send the audit logs to the other services. You can see the audit audit information being shown there. Decide by means of definition in the catalog on the information that are audited by the plugin. And one another way that was started but left as it is considered unsecured is to get the audit logs stored in the database. Though it is half-baked the PR for that is still open, I used to post this debut here. This configuration will be mined by the better UX and will be updated soon with the help of Mac. The last time I spoke to her regarding this she was figuring out how to how to do it. Please try out the plugins and let us know your comments on the channel. It would be helpful for us. And I would like to thank Matt, Jeff and Tracy once again for their support throughout. Thank you everyone. Have an amazing day. Thank you for the presentation. Are there any questions? If not, I have a question. So about the external storage. Since you do C-Slog basically you already can forward this data to LogStash and to other data collectors because they integrate with C-Slog. Have you tried this configuration already? Can you please ask the question again? I couldn't get you. So have you already tried remote storage for audit logs? As of now we have just configured the C-Slog server and we haven't tried that. We'll try. I don't think we've tested out any actual scenarios with it in Jenkins specifically. Though we have used the particular log for J-plugin that we're using for C-Slog stuff have been used extensively in a bunch of other projects unrelated to Jenkins before. So it's sort of one of those that works in theory things but we don't have documentation on that yet. I think there was initially there was the thought of looking into supporting like Postgres or Mongo or something directly until we kind of had second thoughts about that later on when we realized that that wouldn't have been so we sort of had to we didn't really have enough time to test out external log storage yet. Thank you. Another question is about J-plugin. What is the difference between audit log and audit trail and what's the difference? I think I might need to explain this a little bit. The main difference is there's two main differences in how it's architected. One, the big difference is our actual library use. We're using actual structured logging which is very useful for machine readable logs. A lot of people use diagnostic logs most of the time and those are a real pain in the ass to actually parse by your logs collector. The other major thing was that the audit trail plugin implements itself essentially as a servlet filter and kind of just tries to intercept various URLs that it already knows about and then will log those just in a standard Jenkins log. What this plugin does is actually tries to properly instrument all the various listeners or creating new listeners or just directly audit logging from invoked code so that we get maximal amount of information that we wanted as well as let's say it's a I'd consider this far less of a hack job than some sort of URL matching based thing. Now the URL matching thing has worked well enough in the past but I feel like there's a lot more internal actions that can happen that don't necessarily correspond to URLs all the time so far they have mostly but yeah those are the main things and if you want to go take that a step further in theory the audit log plugin is a zillion times faster than the audit trail one because it's using log4j instead of Java util logging which has orders of magnitude difference in performance characteristics. Okay thanks for the explanation. Are there any other questions to ask? Just a general question for me so yeah it's always nice to come to these things and see things and I always learn a lot because it's nice to see what capabilities so specifically I was just going to ask about your experience and maybe what was the biggest challenge you faced on kind of getting this functionality together I can see you on mute so I don't know if you're talking Tuzzi actually first of all communication and understanding the code it was the biggest challenge I was facing that you relied on asking a lot of questions or did you feel there was a lot of self-service information we had for the kind of plugin development actually I don't have any previous experience like this before this is my first time I'm doing these activities okay any other maybe comments on like I know it's hard to compare if you don't have anything else but yeah any suggestions or things we can improve from the Jenkins side I think we'll be well appreciated yeah thanks for the work. Thank you, so in Jenkins project we are doing a Jenkins Retrospective and if you want we can just try combining to result region so we will have another public Retrospective meeting with you and everyone is welcome to join and discuss the results or maybe we could help us joining the Retrospective we'll be happy to discuss it and share experiences between projects any other comments okay so yeah thanks for the presentation Artie I had a question to you so we had two students this summer was the second part covered in the presentation um let me think here so we had the the syslog stuff was a bit part of that we did have a lot of interesting setbacks related to that partly because even me as a person who's been working full time on Jenkins for over a year now is still slowly barely understanding some of the APIs that we were trying to use that are all UI related type of things there was that let me see what was the other thing one second we showed the audit log page that was had a bit of interesting things to it see some of the last things we were talking about weren't delivered yet they were related to that what we were just saying the describable descriptor thing I think we probably covered it since we don't really have a a syslog server to demo with it no we don't really have anything else to show I don't think because we showed you the audit log page itself and the configuration page and the various events I'm not sure if we showed every possible event that's logged but it might take a bit of time to set up so I think we covered everything okay yeah thank you so then let's proceed to the third presentation are you ready there was a message in the chat that there are a lot of issues I'm not really sure we will have a third presentation today so I wish if you are talking you are muted you know can you hear me yes we can so I had a little domestic issue I left the shower on and everywhere exploded but I think I've been able to manage it a little okay so what would be your preference we can do the presentation now maybe we could do it as a part of a pipeline authoring seed meeting or maybe another special interest group meeting so if you prefer to move it you can do it okay let me see I think I'll be ready to move it okay just feel free to share your screen once you're ready is there any other better than seeding as of now sorry then here you are but it means to speak as of now no there is no other presentations scheduled so basically you're the presenter now so if you're ready we can continue if not okay I think I'm going to take the presentation let me just get done with it so did you hear that hello can you hear me yes we can the audio breaks a bit but generally we can hear okay so it looks like the audio is quite unstable wow is it better now can you hear me yes can you see my screen yes okay so let me see so good everyone my name is Onyamin Amdbisi I'm presenting my good project it actually is a particular analysis for CIFI CLM so did everyone hear me yes so CIFI CLM is an open source consistency relationship manager and it is only used by non-governmental organizations and non-profit organizations to manage their campaigns to track how much respondents they've had to send messages to store contacts and do all of that currently we have over 11,000 non-profit working with CIFI CLM including Wikipedia so the question is why static analysis so currently CIFI CLM uses Jenkins as part of this CI CD two chain they only have a unit test as part of what you need to do before a boot request can be made so with just a unit test they found out that sometimes they have subsoil errors which the full request reviewers do not actually get to see so they have to find a way to see if they can be able to check those errors and also tell people that want to come to boot code that you've made these errors and also see how they can fix it there was also a need for something that can scan the code base since the code base has been in existence for some years now they needed something to scan the code base and also mention if there were errors in pre-existing code and lastly they needed that for some quality assurance to improve their code quality so currently the two chain for CIFI CLM consists of GitHub, Jenkins CIFI Core and we should be adding SAM SAM is the tool we are to use for the static analysis and the code base works with PHP so we looked into different static analysis tools for PHP we looked into FAN and we looked into Stan too but we were able to choose SAM because SAM had ease to configure, SAM also had descriptive error messages also SAM was in active development meaning that whenever we had errors with SAM we could actually open issues in the GitHub people and also have the issues solved so that was why we picked SAM for this GSOC project so this is the workflow the workflow was from a developer's machine once the developer is able to push GitHub we should have Jenkins pick up the webbook from GitHub then install Composer and runs all the necessary dependencies then also run static analysis then display whatever errors we have from the current request as part of the Jenkins log on the PR so I'll be discussing some of the challenges I had trying to integrate SAM into the already existing Jenkins I'm switching so since the Jenkins switching was already in use by CVCRM I was given like a separate environment for me to try and integrate Jenkins so to integrate SAM so they provided me with an environment a server that had everything currently in place with the switching in use the only difference was this was just for trial I could make my trials and errors because they couldn't stand me having trials and errors in something they were using for actual development so my challenges with Jenkins was that I actually couldn't use the Jenkins documentation to implement static analysis on request so I had to read and read and read and scrap online so the thing was I was able to see some results that matched what I was looking for but you could hardly find them on the first page of Google, probably on the second page so the documentation I think we need some improvement especially with integration with GitHub and also the configuration wasn't easy at all for Jenkins they had to be lost and lost and of configuration before you can get your Jenkins to work and besides there weren't any descriptive error messages just have to like configure then try to make a full request and see if you had your changes so far am I clear enough hello can you hear me yes we can ok so apart from Jenkins I also had some challenges integrating SAM and the codebin for one my mentor mentioned that it's usually very difficult to integrate static analysis tools to large codebiz because sometimes static analysis tools fail to analyze the codebin at one point or the other so while trying to run SAM on the CVT-RM core codebiz I had some errors but the good thing was that whenever I open issues on the errors on the SAM repository the good people at SAM were able to fix the bugs so SAM is used by Vimeo Vimeo is the video sharing platform like YouTube so since SAM is used by Vimeo the developers were active and we are always ready to fix any errors encountered so apart from the bugs and having them fixed so SAM can actually run on the core repository another issue was the baseline so it was very obvious to us that we must have errors in the codebiz since the codebiz consists of thousands of lines of code and different folders we must have errors but the issue was is there a way we could have these errors but still have the test passing because there wasn't anyway the developers of CVT-RM could fix all the errors shown by SAM before continuing what they were doing CVT-RM was in active use we had bugs that we actually needed like bugs that we had to fix and also had features we had to implement so there was no way we could wait for to handle all the errors thrown by SAM before we could continue so fortunately SAM had a baseline feature which allowed developers to kind of grandfather errors that have already been thrown so these errors could actually be there and SAM would pass, SAM would only look at errors presently in your current code request so that was one challenge but SAM already had a way to control that using their baseline feature when we were able to fix the baseline feature another issue we had was force negatives we were having thousands and thousands of errors from our static analysis that most of the errors spoke about dependencies they were missing like missing class and missing functions but when my mentors were able to look at the code base they found out that those were force negatives as those classes were actually in existence in our code base so they mentioned there was need for us to have a bootstrap file or an autonode file that would put in all the dependencies before static analysis was done so we could reduce the force negatives and then have some errors that actually were true so when I had the bugs fixed and the baseline feature implemented and also had an autonode file configured to reduce force negatives we were able to move on with the project so with that fixed we were able to have some failing text and when we were able to fix those tests we were able to have tests that were passing so that was actually what my book of code project was trying to integrate SAM which is a static analysis into the civic core code base so before progress emerged SAM can be able to analyze the code to make sure we don't miss out on subtool errors so in conclusion I think I've come to love the open source culture because my mentors were full of community and they were also very patient with me most times I was stuck with bugs for weeks and they were able to encourage me to try to figure things out and also to give me one or two tips also everyone in my organization was also very very helpful I also wish to thank the Jenkins desktop team for giving me the opportunity to present my project I'll be sharing links to my final report in case anyone wants to have a look too Thank you Thank you too for your presentation Are there any questions? Not a question but yeah I just wanted to say if I spill a bit of water myself before presentation I'm a mess so congratulations on doing that given the flooding and yeah I've just found that really interesting I wasn't familiar with SAM and I know there's always challenges when you're trying to integrate things like Jenkins SAM dealing with all of that so it's really nice to learn about this and I look forward to the report Thank you very much Miranda One question Did you use any specific Jenkins plugins to integrate with SAM? Okay the plugins I was able to use so I had the Jenkins PR builder we had the Jenkins PR builder I think that was the major plugin I was able to use for GitHub the Jenkins PR builder for GitHub I think that was on the plugin Okay so you don't use Jenkins pipeline so far right? No no no no no pipeline so far just the PR builder Yeah thank you For SAM report publishing did you use anything? So I didn't get that I didn't get that So after executing Psalm, were you publishing I'm sorry I should share when running Psalm so we generate reports static analysis results were you publishing it somehow in Jenkins Web Interface? Yes I think by default Jenkins allowed me to see the log somewhere I don't know if I could show okay I think Jenkins just decided I used the default logs from Jenkins to see the output Okay Yeah thank you If Psalm produces enough information in the logs it's a really nice way to use it Okay Are there any other questions? Is it possible like in Jenkins like specific job like we can create like that log for it? Hello I think the question is not clear enough can anyone help me repeat the question please? Yeah I also didn't hear the question So is it possible to create a Jenkins job for what? The question is like specific job has like a specific log to be set up Is it possible to do in like a Jenkins to make like that log for specific or what? So about specific logs if you use Jenkins pipeline you can retrieve logs for every step so for example if you run Psalm and any other tool from CLI you can get a separate log just for this execution you can access only this specific log from REST API and yeah if you use tools like basically blockchain or just on pipeline stage view you can see specific logs in WebUI Okay so Any other questions? How can I get on this? Yeah thanks a lot for your presentation and yeah thanks a lot for your hard work on my CVCRM I would like to say thanks to all students who presented today and to all students who presented in previous sessions as usual we will be publishing recording on the Jenkins YouTube channel so you will be able to see the recording of the session and if you have any questions join our Gitter Chat and we will be able to answer the questions there. Okay so yeah thanks so Are there any other questions or additional comments before we close down on the session? Okay if not just thanks to everyone I will stop the recording and see you at the next Jenkins Online Meetup maybe in a few weeks. Thank you everybody. Take presentations everyone thanks.