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.  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.  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.  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.


If any of our earls or barrens, or others holding of us in chief by night service dies, and at his death his heir be of full age and o' relief, he shall have his inheritance on payment of the old relief. Namely the heir or heirs of an earl, one hundred pounds for a whole earl's barreny, the heir or heirs of a barren, one hundred pounds for a whole barreny, the heir or heirs of a night, one thousand five at most, for a whole night's fee, and he who owes less shall give less according to the ancient usage of fiefs.


Hi, from the postgraduate and doctoral studies office, we want to welcome you to Pumpeo Fabra University. Now I'm going to show you how to enroll. If you're a master's degree student, you should have decided, together with your coordinator, which subjects you'll be studying in the academic year. You can find out about the tutoring process involved in your master's degree program at your secretary's office. In September, the secretary's office will contact you to tell you where and when to submit the following document, original and photocopy of your university degree, original and photocopy of your academic transcript, passport or foreign ID document. If your diploma and academic transcript are from outside the European Union, you will need to have them authenticated. This procedure should be done in the country of origin in which they were resued before you come to Barcelona. If you're entitled to a discount, be it for disability, belonging to a large family or any other reason, or have applied for or received a grant, you will have to prove that that's the case so that the corresponding reductions can be applied when you enroll. Are you ready? Okay, so let's start. First, go to the registration page and click on Enroll Now. Here's what you need to know about the access codes. Your username is your ID number without spaces, dashes or full stops, and your password is your date of birth without spaces, dashes or full stop. The online enrollment is a very simple four-step procedure. First, check that your personal details are correct, and if so, click on Next to access to the academic details. Here you will see that the subjects that you agreed upon, your coordinator, will be displayed. If you're a PhD student, a single subject will be displayed. It is the academic supervision of the year. Click on Next. Now it's time for the payment. You have two options to make the payment. Buy direct debit in one or two installments. In this case, bear in mind that you will need a Spanish bank account in order to pay by direct debit, or to pay by credit card or debit card in one installment. In this case, the card will be charged upon the completion of the enrollment procedure. And last but not least, check that your personal, academic and economic details are correct, and if so, click on Confirm. And that's it, you have been enrolled. In addition to identifying you as a member of the University community, this card includes a certificate that will enable you to carry out various procedures and use a digital signature. Remember that all the information you need can be found on this website. We recommend you to download the print version of the online enrollment guide so that you can follow the process more closely. Enjoy your studies and welcome to Pumpeo Favre. See our website for information on UPF card delivery dates.


Welcome to another video. That's the new cringy intro that we're gonna be adding to these I know I did in the last one nominee you guys said anything about it So I was like we're adding to this one guys today is a very special day I'm super excited about it because I'm gonna be able to take out my new bona fide kayak right here for the freaking first time I am so pumped about it, but I have a few things I do want to talk about before this video gets started. There is one thing that I Suggest everyone out there, especially if you're in a kayak does and I already made my first mistake But let me address that so when going out in the water obviously safety, you know is what matters Having a life jacket is what matters as you guys can tell on the back of I got Alan Bob behind the camera by the way Yeah, yeah, I'm involved on the camera. He's got we have one life jacket with us My boat actually ended up breaking down last week. I took we it's actually in Atlanta right now Life jackets are not in there. So currently only have one with us today. This pond is only four foot deep There's two of us out here right now I'm just learning the basics of me getting in my kayak and kind of you know Getting around and figuring figuring out, you know getting comfortable with myself. I'm just kind of getting ready today It's not like too much of it But I'd rather get out there and at least dump it in the water for a minute And I fish around just a little bit and show you guys I just wanted to say that in advance because I already know there's gonna be some people freaking out They know it's not both of us have a life jacket on or whatever it is But just I'm gonna let you know it's only four foot in there every single other time I go out on the kayak literally every single time. I promise you I will have a life jacket on I'm actually gonna order one tonight, especially for the kayak like like special for it Yeah, you guys are wondering why I haven't filmed a kayak video yet. I've been super super busy lately Literally has been unreal. There's been a lot of changes in the fishing team here We're trying to have practice every single day. I'm class has obviously been hectic I actually changed my major like there's a lot of big things I've been going on and also me filming in general I've been doing a lot of pond fishing stuff Not even boat fishing because I've literally been that busy is what I have to do But anyways guys, we're about to dump these bad boys in for the first time I am gonna make a full-on kayak tour where I'll pretty much discuss this This is the SS 127 if you guys are wondering I'll link Bonafide links down below if you guys want to go check them out on social media We're actually partnered up now But more details than that coming soon when I start to talk about this bad boy because I kind of want to show You guys in depth but for today. This is my first time going out on the old kayak. Let's get our Alan Bob Are you ready dude? You ready? This is old Alan Bob's kayak. He's about but you got this recently too, right? So he's kind of new to kayak fishing right?  We're about to take this boat for a test drive Well, this is probably a different site that you're gonna see for me and I'm excited about it We're about to start kayak fishing baby fishing out of this beautiful bonafide boat is gonna get real guys I'm super excited if you guys want to see some more kayak fishing videos be sure to pepper that like button up, baby Let's get it started careful Alan Bob Can't lose you man This is crazy Alan Yeah, it's very stable like I'm impressed I guess gonna take a lot to Yeah, I'm not gonna lie I'm almost stuck in my pull in the water like three times now I'm so used to being on a boat in you guys are wondering what I'm rigging up today It is just an old simple drop shot Which is not surprising because that's what I've been fishing with the past about I'd say two to three weeks I've been killing them on a drop shot one of the most finance baits out there If you guys aren't throwing one I highly suggest it I did make a video on the you know What to throw when it's super tough and a drop shot was definitely my go-to option as you guys can tell us got a Four inch old zoom finesse worm just regular and green pumpkin and we're gonna get out there and see what we can do There he is Dude, it's a good one, bro. I'm serious.  He's a good one Bro, that is a fat fish our baby, that's my first freaking kayak fish ever let me take a look at this right here Dude, that is seriously a fat fish first kayak fish first fish on the old drop shot first fish of the day with Alan Bob Over there. He still has to catch his first one We're gonna make it happen today though, but first kayak fish ever that is sweet Rigging this old drop shot back up.  We're about to catch another one Got one Yeah It's a small. Oh, he came off Oh Alan Bob is hooked up with his first kayak fish This is awesome Get her Alan There you go. Good job Bob with its first ever kayak fish dude. There you go. I'm not a bad one He's solid pounding a hat. Do they're thick bro.  That is a solid one, bro God good job though.  He just came up right there. Do you see that? That's freaking sweet. Oh My god, dude he ate as I was reeling in. Oh My god, dude Second fish on the drop shot. I was just reeling it in just slammed it.  That is a beautiful fish on the old kayak. Gosh. This is actually really really fun There we go guys third fish of the day my second kayak bass. They have all been so fat so far in the old backyard pond All right, buddy Here he goes There you go. That was freaking awesome third fish of the day second fish on the old kayak I'm having some fun with this big shout out to bonafide if you guys haven't checked them out Please go check them out. I'm just having a blast. This is awesome that fish I was thrown a drop shot same old deal I was working on the bottom and I started to kind of hop it a little bit more and I just started to reel my bait in And right when I started to really he just started hammering it and he just had it. That's insane That's three quote pretty quality fish right there. We're gonna see if we can keep on fishing and catch a few more Holy freaking smokes people. I know yesterday. We pretty much got off the water. We caught three fish total There's a blast my first fish Alan Bob's first fish on a kayak ever. We're about to go out today So I got Alan Bob right there. Go follow him on Instagram. I'll pop it up right there Alan Bob He's got his kayak all loaded up. So show me what you have tied on Alan. I got I got the same thing pretty much But so we got a ratio crawl or the speed crawl speed crawl I get them confused, too I thought on a drop shot probably throw a natural color on it and I'll know so good too. He's no second is I have mine where it's weedless Which is just what I already had on like out here. There's really nothing. It's probably better to know so good But that's like I got on just old regular four inch finesse run That's what I caught him on yesterday He caught his on the old crawl and then I do have a speed crawl as well rigged up right there Texas rigged And that's some juice that's all we're bringing today But pretty much the reason why we only have slow-moving baits on today is because if you look in the sky There is literally zero clouds out. It's kind of how yesterday was to I'm expecting today to be similar to yesterday If not, maybe a little bit more tough I just it's one of those days where you're just gonna have to slow down drag a drop shot You know drag a worm throw a crawl drag it on the bottom It's just one of those days, especially when it's bluebird skies zero to no wind I mean, there's a little bit of wind As you guys can tell like a tiny bit here and there but there's really not much But we're about to drop her kayaks in the water and go catch some back If you guys are wondering what tackle I'm bringing today pretty much is simply my old drop shot box And then I got under my seat I have simply an old Texas rig box with some more rage crawls pretty much is what we're throwing today And I only have one worm that I'm bringing on the boat. We're keeping a very basic very simple Just you know standard old trick worms by zoom is green pumpkin just really simple That's what we're bringing on the kayak today. Let's go put them in the water boy Yeah, Alan's hooked up at the first fish. Oh dude. It is a good one.  That is a freaking fat fish hold them up Alan Bob Got Lee man.  She's stomach Dude, what is the stubbiest fattest fish I've seen that is awesome on the old drop shot good freakin job, bro Let's uh, I'll get you a picture. So you want to put them right here? Yeah in between the kayaks There he goes. Oh, yeah, boy. That's good It's a good one. Oh my gosh Let's go, baby.  They're so healthy and fat That is just awesome right there on the drop shot second fish today.  There we go Alan. Good job. That's what third one today Hey Let me see with them up. There you go That's a good fish dude this third one today.   You know how I was always talking about flipping in that stuff. Yeah He just came right off. He took my whole crawl. All right guys another fish I literally flipped in there with my crawl. Yeah, I literally reeled it in on top of the water And he just came up and smacked it. It was insane. Let's get release on them. So everybody This is the first kayak fishing guy. Yeah. All right, everybody This is the first kayak fishing video ever on the kick in the rest TV channel I hope you guys find that you too Enjoyed this video if you guys did be sure to pepper that like button below I want you guys to let me know if you guys want to see some more kayak fishing content because honestly, dude I had a lot of fun Like seriously, this is something totally different big shout out to bonafide if you guys want to check them out I will leave their links below Yack attack as well if you guys saw, you know the first fish of the whole clip in the video I kind of whipped out the old net and Just just whipped the thing out and scooped them all up But thank you guys so much for the support leave your suggestions below the next kayak fishing video I think should be a challenge So if you guys have a challenge in mind Definitely, let us know and it's just so efficient because the pond's right there So I can just call Alan Bob up and you know tell them let's go kayak fishing we can do a challenge Maybe it'd be like a 1v1 maybe to be like a Walmart challenge. You guys let me know in the comment section below Thank you guys so much for the support I love you guys so much and I'll catch you guys in the next video Everyday


Since the name of your song and it's a little bit like charades. So you're gonna have is it 15 minutes They've got 15 minutes to design your sculpture and then from team to team We're gonna go around and guess what your song name is So try to make it something your other people can guess otherwise you can't be winning. Do we have prizes? We've got prizes Any questions the question do I have to do it is not appropriate any other question Yes That's true, so you they might not know your teams either so you want to try and make it as As much familiar for the other audience as it is familiar to yourselves You may so instead of any song can we say nursery rhyme because everyone yes familiar with them nursery rhymes Nice And build something out of it build something from yourselves Okay, you time for 10 I'll time for 15 So we're gonna do 10 minutes and you guys need to decide a nursery rhyme That is your favorite nursery rhyme and then build a sculpture that represents that nursery rhyme and other teams have to guess What that rhyme you are? Guess your rhyme. Yes Can it be a kinetic sculpture? Yes, who are you planning to throw? Just move just move. Yes, of course So I had five This one in the rain one seemed to me like the most Any song or nursery rhyme yes, it's okay, right? Oh, no, no, sorry any nursery rhyme. I beg your pardon It must be a nursery rhyme So For whom exactly which children All right Remember that


Hello. I am Suley. I work for Veebooks. I'm an engineer there. I'm also a flight maintainer. And I just wanted to also mention that just a little shout out to Suley that he was very instrumental in getting Helm OCI support into Flux and also was the person who implemented Helm Cosine verification in Flux. So thank you very much. Yeah. Well, you might be walking in for the first time, so I'll just say I'm Scott Rigby from WeaveWorks. I'm also hosting the event, but I'm giving this talk as well. I am a Helm and a Flux maintainer. So thanks for joining us, everybody. So today we're going to be talking about the integration of OCI artifacts as sources in Flux. You know, Flux has the concept of sources and they can be Git as a source, OCI, excuse me, S3-compatible buckets as a source, Helm repositories as a source, and now OCI repositories as a source for everything. We're going to start with an intro where we'll see what OCI artifacts are, what their advantages are, and why we even want to use them. And we'll then cover new features, introduce and Flux around OCI artifacts. And finally we will have a demo and we'll give you some info at the end of the links. Okay, right. So thanks, Eli. Yeah, so what is an OCI artifact and why would we want to use it? So what we're showing up on the screen right now is something that many of you should be familiar with because you're here at KubeCon. But if not, in either way, we're going to do a comparison with artifacts and OCI images. So this is an actual, the JSON for an OCI image manifest. It is an OCI for everyone, hopefully, you know, stands for Open Container Initiative, and it's essentially what happens when you build a Docker image or use any other OCI compatible tool to build and distribute images. So the image manifest describes the components that makes up an image. So it's basically what pretty much everything that you will need to run a container down the road. And the config layer that you see at the top contains layer ordering information.  So that you want them to go in a certain order, generally speaking, and excuse me, and what basically what needs to be applied in order to get root file system. So the digest feature, or the digest key up there is a cryptographic hash of the compressed content of the target component. So the media type, and then the media type will tell us, excuse me, what compression standard is going to be used. So the OCI.image.config.v1 plus JSON gives you that, that's what I'm talking about, and it gives you that information. And so, you know, the digest is similar to digest for other things, and it's a unique, a unique hash. So if the content changes, the digest will also change, right? So when fetching a manifest, either the config or a layer, we have to apply the hash function to verify that it's consistent. This makes the content immutable and addressable by its digest. So what you have on the other side is an OCI registry, and that is where we store images. The registry gives us a nice API in order to handle OCI images. If you look at the top here, you can see we have several endpoints for every kind of component we have. We have in the endpoints, resources identifier, you have the name, and you can do some access control based on the name. And on the top, you have the tag endpoints that we can use for content discovery. So we said that digest are immutable. Tags are immutable. You can use tags for human readable versioning of our images. So if you use tag endpoints, we can do content discovery and retrieve tags for given image. Then we can use the manifest endpoint and giving a reference. So a reference is either a tag or a digest. We can retrieve the manifest. Once we have the manifest, we have everything needed to pull the configs on the blobs of our given image by pulling using the blobs endpoint. So we want to show you this because OCI registry gives us nice features. We have content deduplication. We can do reasonable push or pull. And the OCI registry is doing garbage collection as well. If an image is not reference at all, it's garbage collected first. Okay. So at some point, users really wanted an artifact. Basically, a type of OCI thing that can store other artifacts that are in containers, right? So basically, it was important to be able to... Oh, actually, do we show the artifact type? Yes. It's here on the config. It's a type. Oh, the media type. Oh, I thought you actually meant the artifact type. Yeah, yeah. So basically, this is the standard... Excuse me. Artifact type for Helm. It's registered as a media type. And that's the application vendor CNCF Helm config V1 plus JSON type. So that allowed people like, say, if you're using tools to get information from an OCI registry to say, hey, I just want my Helm charts that are stored there. In this case, it's Helm charts. Other artifacts can be stored as well. And you don't want to, say, parse through all of the container images in that same registry. This type was a thing to allow you to do that. And the Microsoft... Well, what was then the Microsoft project, which is now a CNCF vendor independent project called ORAS? Which is OCI registry as registries as storage has a really good tool set to allow these things. So you don't have to do it by API, but you could. Yeah. And we've... I'm looking at my speaker. Sorry. Yeah. I mean, ultimately, the idea is to use config media type for this. But, you know, users... There is a thing that was just added called artifact type. And that's... I think that's what you meant there was that that is a way kind of to categorize artifacts so that you don't have to register every type. So you could say, I have six different artifact types. You know, one's customized manifest, one's Helm charts, one's OPA policy, you know, whatever, right? And I want to be able to get only those things through an API. It wasn't really easy to do that unless you specify the media type. And generally, you have to register that if you want to use it for anything besides internal use. And so what the spec chain... Basically, with that addition, very soon, you'll be able to not only have a different media type, but you'll be able to use the standard media type for artifacts with different artifact type keys. So why would you use OCR artifacts? The first use case is, in order to collocate your code on your configuration, you could, for example, for those of you that know about flux image automation controllers, today we use this to automatically reconcile actually our code on application. Every time we have a new version of our code, the image control automation is reconciling it for us into our Kubernetes cluster. Today, if you have OCR, you configure OCR artifacts, you can do the same things with your configuration. The second thing is consistently referencing your images, with your digest, you can do tag versioning, and you can do access control as we showed with the registries. Let's take this OCR. Cool. Right. Yeah. So basically, we're just showing you the difference how you migrate using... If you're a flux user, how you migrate from using a Helm repository to using your charge stored in an OCI registry's repository, really it's just these two things. That's the square of red around there. It's really in the spec URL.  It's the exact same URL that you would pass for where your OCI charge is stored. It just needs to use the OCI scheme in the URI. Maybe just... Because on the left, it's a Helm repository with an index, an HTTPS one that we say, and on the right side is when you move this to OCI. Yeah. Yeah. Good distinction. Yeah. So we should probably say that, yeah, that the HTTP Helm repository, if for anyone that doesn't know, has an index file, that lists all the information about all of the charts in that HTTP Helm repository and all of the versions for each of those charts. So there have been cases... This is a pretty important point for people that are concerned with bottlenecks. For example, you may or may not have ran into this, if you're a legacy, chart user for Bitnami. Bitnami is one of the major chart, distributed chart sets of maintainers who rigorously tests their charts and images. And just they've been doing this for a really long time. And so a lot of folks trust them. They had to truncate all older versions from their... Beyond a certain point for their charts, because just the index file was like something like gigabytes. It was just ridiculously huge. And the reason that it needs that is because it doesn't have something like OCI, which has its own API for doing tags listing and things like that. So that's the only actual functional change you need to make in your CRDs for Helm repository. The other change, it really just... If when you're moving from a Git repository... So that was from a Helm repository to an OCI repository. If you're moving from a Git repository as your source, it's really just that. You simply change the URL instead of pointing to your Git URL, you point to the URI for OCI. And Sembr and everything works. The Sembr constraints, the ranges and all that, they work exactly the same. So we have also implemented an integration with cosine inflex. So just to tell you how cosine works, cosine is used to sign OCI artifacts. So the way it works is you create a key pair and you keep a curve key pair. You sign your artifact manifest and you store the signature with the OCI artifact. And in order to do the decryption, the verification, you retrieve the signature from the registry. You verify the signature against a public key and you verify the claim as well. Verifying the claim means you have a payload in the signature that they knew what digest, manifest digest has been signed and you verify that the digest correspond. And there's an experimental feature that is a transparency log that can be used. That's how it does work. So let's just show you how we do the Helm release reconciliation. So for this, we assume that we have a Winning Flux controller or Helm controller or source controller and that you have applied a given manifest. Then how does it work? From a user's perspective, you push your Helm short to your OCI registry in your repository. Then Flux's source controller is managing Helm repositories and Helm releases custom resources. So what it's going to do is first pull the signature. So this is optional. That's why we have this. But if you have enabled it, you pull the signature and you do the chart verification. If the chart verification is successful, you can move on. If not, you have a nice condition in the custom resource when you do keep cattle described that's showing you why the build is not successful. Otherwise, after the verification, it is going to pull your Helm artifact, build the Helm artifact with the given optional value files because what we do with source controller is the default value file is not included if you do not specify it. Then you package the chart and you store it as an artifact with the location that can be used. And then the Kubernetes API servers receive a notification and notify all watching controllers. And one of the watching controllers is Helm controller. What Helm controller is going to do is first fetch all the values that you have set into your resources, the resources being config maps and secrets, fetch them, merge them together, and then it will fetch the artifact and we'll do the deployment of the release. The deployment being either a Helm install or a Helm update. And then it's the same process that exists today. We have also integrated, while integrating OCI, we have also integrated contextual login. And I think this is you. What we do, this is something that we already had with the image automation controller. What it does is that it takes your image, your cloud provider identity service. And if we specify that we want to use a given provider, it will use the workload identity either to the service account, attach your controller, either to the node, just the identity attached to your node. And what it's going to do is instead of providing a secret with authentication tokens, you can just set a field provider with the name of your cloud provider and what Flex will do is Flex will ask your cloud provider for a token in order to authenticate and be able to pull the given artifact. Go on, Scott. Yeah. Only one other node I wanted to mention about that is it's actually a, yeah, sorry. It's a key on the OCI registry custom resource definition that just says provider. We didn't put those in the earlier slides because we didn't want to confuse, didn't want to add that new functionality when we were talking just about migration. But yeah, you just simply say GCP, AWS, et cetera. And the open ID connects. We support two provider, GCP, AWS, and Azure cloud. Yeah. And, you know, the CLI has some, the Flex CLI, again, you don't need to use the Flex CLI in order to be a Flex user. It just, it's really handy. So most people like to use it for different things such as this. So, for example, you could use the Aura's project directly to build your artifacts, but Flex has built in tooling to call that just like Helm does for, you know, the build, push, fall. So these are the commands, Flex build artifact. You specify a path to where your manifests are when you want to package them up. And again, since this is for customized controller, it can be, your manifests in this case can be plain YAML or customize overlays. And then you just give it an output where you want the packaged artifact to live on your file system. You probably, some of you may have seen Pinky's talk earlier where she just, she talked about terraforming Flex. So in that, that's an example of if you're using a controller that reads manifests that are packaged in a different way or represented in a different way like your terraform plans or excuse me, your terraform resources, your path would be toward that directory where you keep those or the single file. And then you can do this, essentially use Flex CLI to push as well. It uses the same API under the hood. You just do your Docker login to get your config or however you want to authorize to the registry that you want to use. And you just do a flux push. You do the same thing. You give it the path that you, of the repo, excuse me, you give it the URI of the OCI registry that you want. And then the app, in this case, that's the repo. And then what this is doing is just getting the tag, the path where you want your manifests to come from. Optionally, if you hadn't already packaged it, you give it your source. The source is on the way, then you put this as annotation, actually, on the artifact. Right. Yeah, exactly. So it can comply with OCI annotation information so that you can parse that with your tooling. And in this case, why are we adding the revision now that I'm... Actually, what we do here, we take the, because this is from Git, we get the current Git commit and you put it as a revision, actually, as an annotation when you push artifacts. So when you push artifacts, you have the annotation. And you can see it on the flux side in the custom resource. That's so awesome. Suley knows more about this than I do, obviously. That's really great. And then there's also the pull command. And it's almost the opposite of the push command. Because you have the demo. Now, for the demo, we have... We will be using a fork of Podinfo from Github and Toran. And we have two scenarios. The first one is that you are going to migrate Podinfo Kubernetes manifest from Git to OCI. So we will be handling packaging and pushing the manifest to Github container registry, signing it with cosine and deploying them to Kubernetes. The second one is the same thing, but you will be using the provided HelmShot to migrate it to OCI. And again, packaging, signing and entering to Kubernetes. So, yeah, we use a fork of Podinfo. As I said, Podinfo is giving us manifest. We have customization, HPA on the service, deployment. And we have added or shared... We have added... So here we see the deployment. I'm just going to move on. And what we have added is we have added a secret, a sub-uncripted secret, just to show you how we can package together many different manifest. So this is encrypted with H. What we're going to do is we're going to package our manifest as a Tor archive. And then we're going to push them to OS. First, package them. So we put what is in shared and what is in customized in the archive. We show you what's inside. And then we're going to push with OS. When you push with OS, what we're going to do is we give the location and the name of the OS archive with the tag, and we provide as well the major type, which is going to be a layer of tar and compressed with Gzip. So then we push it. And that's just to show again that you can push with either Flux, CLI, or OS. So we have the digest. What we can go is look on GitHub that we have new digest, which is 6.2.2. Then we're going to sign it. In order to sign it, we use the cosine CLI that will be generating asymmetric keys for us, private on a public key. And we're going to sign our artifact with the private key. So when you sign, you specify the location of the artifact and cosine, you're going to pull it, retrieve the manifest, and sign it for us. And then push the signature collocated with the manifest. When it is pushing the signature, what we can see here is that it set the tag for the signature, finishing with that sig, and the tag actually is the digest of the manifest, of the OSRI manifest. So now this is done. So we need actually, we need the public key in order to do the verification in Kubernetes site, so we create a secure with this. And then what we're going to do is we're going to, what's coming back, we're going to deploy an OSRI repository, then put in full, with the location of our OSRI artifact, and we're going to provide a somewhere, and at the end, what we do is we set a verify field with the provider, set to cosine, and we give the security friends containing our public key. So we apply this, and then once it's applied, we can look at our custody, our OSRI repository, and here what you can see is that we have an artifact, the artifact containing our manifest, and you can see at the end that we have a six, in the condition, you can see that we have a condition type source verified, and that it has succeeded. And you have the verify the signature of the given revision. So now what you're going to do is we're going to, using the Flex CLI, we are going to create a customization that is going to fetch the artifact set by the OSRI repository and apply the given manifest in Kubernetes. And you provide the self-deception key for the, for the self-secret. So this is applied. Here we, what you can see, if you look at the status, you can see here, or we have a customer, the customer is giving us an inventory. In the inventory, you can see what this has applied.  Those are all the manifest that were part of the archive that you pushed at the beginning. So we look at them then, we check that all of them are ready, the deployment. And also we have checked that here we can see the secret. The secret named record has been decrypted. It's a local configuration. It's not, it's not anymore a substantive secret. But that was the first one. So let's move on to the second one. So the second one is now, so this is not the second one. This is the second one. It's putting for providers also with a chart. So here we have the Helm chart. The version is 6.2.1. So let's move on. What we're going to do is we will package it with the Helm CLI, Helm package, and then we will push it to, this time we are using, we are using a GCP artifact registry, and we are going to use the experimental feature of cosine. We are going to do a keyless signing. So we package this, we push it, we check that we have a new version 6.2.1. Then we do experimental cosine. So when we do the experimental cosine, keyless signature, what it's going to do is it's going to authenticate us with the new IDC scheme. So what we're going to do is it's going to authenticate us because what it's going to do is it's using the special certificate authority to generate a really short-lived certificate to do the signature. Short-lived meaning 10 minutes here, when you generate the certificate as an alternate name, you will have your email address, actually. This is something to know. So now this is done, and here what we can see is that it has signed and pushed the signature, at the bottom we can see that it has signed and pushed the signature to our registry. So then what we're going to do, the same thing here that we showed, our helmet repository pointing to our location, and we have set provider GCP here. That means we're doing contextual logging. We're asking Helm, we are asking Flex to use our identity, not identity, to fetch our artifact from that registry without providing any authentication token or anything otherwise. And then we declare a Helm release that is pointing to this repository that we fetched putting for and apply it for us. So let's see what once we do this to be applied everything. So first we declare the Helm repository. We see that this has succeeded. So it has succeeded in logging and verifying the authentication to our repository. And then we see the release. And we see that the release has succeeded and it has installed to put it for the Helm chart. And it has done the verification. Perhaps we can see here that we set verify provider cosine. And if you look at the Helm chart itself, we can see here that the Helm chart has set the artifact. And then in the condition we can see that the source verify has succeeded as well. And that was the end. So it was we showed. Can you just do the conclusion? Yeah, yeah, absolutely. So basically, thanks for we're maybe going over like a minute and a half, two minutes. So then the coffee break. So basically, just like wrap up a couple of links and some just info how you can get in touch with us. So basically, again, why are we transitioning to OCI from Helm? It's to make sure that we adopt the same delivery. It's when you want to, I shouldn't say, when you want to adopt the same delivery mechanism for applications and configs. So there's also no scaling issues. Related to the index.yaml that I mentioned before as an example with Badami, but that's just one example of many. Really, every time you call out to the index file, you're making another round trip. So it takes that away. It also enables charts, signature verification the same way that you do your images. And it as Suley was just showing in the demo, you can leverage your provider ID service for often. So and then why would you transition to OCI? Very similar first reason adopting the same delivery mechanism. You also avoid distributing objects with different life cycles within the same repository. And similarly, you enable your config objects, sig verification using cosine. It also allows better access control over a given artifact. And the same with your off end as well. So there's some links if anyone wants to screenshot it. We'll also upload this PDF with these links. And please, please, um, yeah, please stop by the flux booth. We've got a lot of good talks coming up on this topic and other topics. So, uh, thank you very much.