and we are live. Welcome to the February 2019, the monthly meeting of the Jenkins Pipeline Authoring SIG. Then we are going to start with Austin Witt, who is going to present his work on Jenkins Spock, test framework for Jenkins Pipeline, which he presented at Jenkins World in San Francisco. And then we're going to talk about the ability to improve develop for experience while working with Pipeline, which I'm probably going to butcher your name here and I apologize. Marcin added to the agenda. Do anybody else has anything they'd like to add to the agenda, you can feel free to do so on the agenda slash note stock that I shared on Gitter and in the email and then currently presenting. But, oh yeah, that's right. Martin wanted to talk about something too. So I'll let Martin add something to the agenda. Bonjour, Martin. But we will start now with Austin, so I will stop presenting and we'll get to hear about Jenkins Spock. All right, I got to figure out, is it possible to share one's screen with Hangouts? Yeah. Up her left, there's a green screen with an arrow. You can share the whole screen or an individual window or whatever. Okay. And then, all right, and presented to everyone, no one else, and you're in the matrix, okay. Okay, so this should in a moment stabilize to looking at github.com slash homoay slash Jenkins Spock. Is that where we are? Looks like, yeah. Okay. Can you make it up the size by couple of notches? Command on the plus probably. Yeah, it says that it's, okay, there we go.  As was mentioned, this was presented at Jenkins World 2018, which means there's a video recording of the long form 45 minute presentation. I'm not gonna redo that presentation because you could just go watch the video. If you just search for a unit testing pipeline Jenkins World in your favorite search engine, you'll find CloudBees site with a link to the video to watch. I'm just gonna cut right to the fun code part of this, which is, so you've got some pipeline code, you've written code to guide your application through its life cycle. You ought to test that code that you wrote, probably used to doing this for your application itself, but now you've written code for the pipeline, so you need to write some code for your pipeline, some tests for your pipeline code as well. Fortunately, you can do that with Spock, the industry standard unit testing framework for Groovy. This library allows you to, it takes care of getting all of the Jenkins pipeline steps in to scope as Spock mock objects, so that your pipeline code that you've just written will just work in any pipeline step that isn't there because it comes from a plugin or somewhere on a Jenkins master, will get mocked and instead of errors when you try to run your Jenkins file, you'll get interactions with mock objects where you can then make assertions about what should have happened or stub responses, et cetera. Luckily, this library, in addition to having pretty great, if I do say so myself, and thorough documentation for how to do each particular thing you might want to, also has some examples for how to test a whole pipeline of Jenkins file, how to test a shared library and how to test a, well, we'll take a look at it, how to test that format where you've got a Jenkins file but you also break something out into a separate Groovy file. So we're just gonna take a look at those. So over here, I have cloned that. We're gonna go into Jenkins Spock, we're going to the examples and we're gonna start with the whole pipeline. So this is a Python web application and it has some unit tests for the Python code, but it also has a Jenkins file, not the best view. Let's take a better look. It has a Jenkins file and it's got this function called deploy, which is a, as just minimally filled out, not actually gonna work, but try to give you an idea of, try to kind of be like what may be an actual C to the pants deploy function would be like. It's got the pipeline proper where it checks out the code, it assembles the amp. Yeah, when I hop in here real quick, I'll stand again, zoom that up just a little bit. I know you're going through this, but for people to be able to read it. Okay, if it would help, what time am I supposed to end my part of this presentation? That would help me modulate my speed. How long are you, if you were going at a comfortable speed is for you, how long do you think it would take? 45 minutes. All right, let's go at, let's try to get 30 minutes. Okay, at 10.30, I will stop. Or, sir, okay. So this example is showing how to... But also, can you, Austin, can you zoom this up a little bit? There you go. All right, I'm not looking at what it looks like on Hangouts because that does the matrix thing. So thank you. Like I said, I'll just tell you perfect. Thank you. Okay, so this is a simple Python web application. It uses Flask, it says hello, and then it keeps counting the number of times. It has unit tests for it. It has a Docker file to assemble a thing. If you run make test, it will really quickly build the Docker image and unit test the Python code. Great. But we have this Jenkins groovy code over here that is non-trivial, it's 50 lines that guides the application through its life cycle. We need to unit test that as well because it's code that we wrote. So there's a deploy function that can deploy to one of many environments at our company. And then there's the mock pipeline, not mock, but a simple kind of hypothetical pipeline here where the code is checked out. The Docker image is built. The tests are run on the application. We will send a notification to our Slack channel if the unit tests for the application fail. Assuming that they pass, we will push up our application Docker image, send it out to the test environment, and then if and only if we've been building the master branch of our project, we'll also ship it right out to production. So there's a whole bunch of things going on on this pipeline that conditionals, expectations, that we might want to test. Things, you know, so what does that look, what would that look like? Well, I spent time on this in the Q and A in the Jenkins world recording. There's been several other attempts to bring unit testing to Jenkins pipeline code before. Each of them has some trade-off or caveat. Either you have to write your code a certain way in order for it to be testable, or there's only certain kinds of assertions it can make about the code at HomeAway, where I was working, we had the problem where multiple teams were producing shared libraries and Jenkins pipelines that were more or less entirely unique to their use cases. And we needed some, my team, the DevTools team needed to be able to offer some guidance as to this is what you should be doing to guard the quality of all this new Jenkins code that you're producing as you move to Jenkins. All right, so what do the tests look like? Well, it'd be not, we'll look at the, so we're using Spock, which is a industry standard open source unit testing framework for Ruby. I think I have a link to it in the readme of Jenkins, Spock, yes. So it's Spock somewhere, I don't have a link to it in the readme, but it is in the presentation. There's a Spock host and interactive website where you can put together specifications and code and play around with it without having to install anything. But the Spock unit tests are pretty idiomatic. There's a lot going on here, but let's look at just. If I may interject briefly, if you have any familiarity with things like our spec from Ruby, Spock is directly inspired by that. The sort of kind of specification model for tests rather than the traditional J unit style of just running a bunch of code and checking what happened. Okay, so let's look at this one test here. In the, so the way Spock works is for every piece of code you wanna test, you have a piece of code named that ending in spec. So to test our Jenkins file, we have a Jenkins file spec. I'm gonna look at just one test here. Groovy lets you do strings as method names. So we've got a descriptive name for our unit test. We don't have to do camel casing or underscores trying to string together something useful. We can literally just type the assertion. We're gonna look first at the when part, when we run a Jenkins file, that's pretty idiomatic. Then we would expect, well, what we're testing is that Slack gets notified when the tests fail. We want to make sure that our Slack send step, that is over here, when we try to run the tests of our application, if somehow they fail, we want to notify Slack. So we're gonna make sure that we see that step called and our setup is saying that when we call SH in our, the SH step, the shell step in our pipeline script with that thing that is us running unit tests, we're going to stub it to throw an exception so that when we run our Jenkins file, we get an exception and then we would want to assert that we did in fact see Slack notified. Now this could be a lot more sophisticated and probably would be in the real world. You'd maybe want to make sure the right things were sent to Slack. You'd maybe want to make this a little bit generic so you didn't have to update it in perfect lockstep with your Jenkins file. Maybe you would want to make it a little smarter to know that whenever tests ran instead of just this one invocation, but the core idea is there. So how do we get a Jenkins file to be able to run and where are these pipeline mocks coming from? Well, those are the two main things that the Jenkins Spock library does. So if we scroll up to our Spock specification, a normal Spock specification starts in this format, some class, whatever your thing is extends specification. If you want to test a Jenkins pipeline, well, add the Jenkins Spock library and then extend Jenkins pipeline specification instead. In setting up our test suite, which is a most unit testing frameworks have this it again, JUnitRSpec as well, we're going to load a pipeline script for testing and it is gonna be our Jenkins file. That is a method from Jenkins Spock that reads the groovy text, parses it into a groovy script object and sets up a mock for every pipeline step that exists so that when the Jenkins file has something like stage or sh, something that we didn't write isn't defined in our code, that hits a Spock mock object that we can make assertions about later on. That is where what getPipelineMock is doing. It is getting the mock object that was automatically created for us, which is why we need a method to do it since we don't have to define it explicitly in our unit test, it's just there for every pipeline step that exists. Because the Jenkins pipeline script is a script, you can get the binding of it and set variables on it as well. You would need to do this for environment variables like SCM or N, things that Jenkins injects into your pipeline scripts that don't come from a step necessarily and aren't explicitly defined. So in this case, if we want the checkout SCM step to not error, checkout is a pipeline step. SCM is a variable that Jenkins injects. We have to be Jenkins and make sure we inject a suitable value for that variable or else we'll get a null pointer. But that's really the extent of the idioms necessary to get started.  Everything else in this unit test is just straight up regular industry standard Spock syntax. So all the public documentation, all the stack overflow posts, they'll work for you. You have all of that resources to help you figure out how to write tests. There's no, well there's, the secret magic is limited to a few specific things like get pipeline mock. And so you can use that to get pipeline steps. If you wanted to mock something yourself, you could also use the regular Spock idiom of, you can also set mocks up yourself if you want. And I'm gonna jump over to the groovy doc for Jenkins Spock where we can see and show a little bit more about the secret magic that this all brings in to make testing pipeline code easier. Then we'll look at unit testing a shared library which I think is the thing that most people are most excited about and then I'll be done. So we're gonna come over to Jenkins Spock and jump into the groovy doc. The thing, all the magic happens in Jenkins pipeline specifications. So I'll bring that up in its own window. So we saw testing groovy functions. You don't need anything. That's not really special, that's just stock Spock but it's here for completeness. Testing pipeline scripts, we just saw that. Load your pipeline script for test, hooray. The other thing that you can do is you can mock pipeline variables. Those are the two main extension points that Jenkins pipeline scripts have, steps, obviously. But also global variables, well, you can mock those as well. There's the syntax for mocking method call for accessing the mocks for method calls on pipeline variables is a little different. You do the access to the method all as a string and then that's your mock object. But it's explained here. We'll see that when we get to the example for a shared library. So don't worry too much about that now. I am speaking a little fast. Gonna slow down a little bit. There is a section explicitly on mocking your variables that are coming in from the vars folder of a shared library. If for some reason something is not automatically detected but you still need to test it, you can also explicitly set those up. The Jenkins Spark tries to identify all the pipeline steps that exist, identify all of your code that's going to need to call them and put those together so you don't have to do anything manually. But you can manually prepare additional objects in your test suite to call pipeline steps. You can mock pipeline steps that weren't automatically detected and you can mock global variables that weren't automatically detected. Probably though, that means you ought to change the way you've set up your project so that they are automatically detected so that you can do less work. For some corner cases, the Jenkins server singleton itself is mocked as well as a couple other things. And there's a warning down at the bottom, don't that if you're using groovy metaprogramming in your pipeline code, it will probably conflict with this and you maybe should reconsider your design. So let's, and so all of these are, they got links to the rest of the documentation, code examples, where necessary, showing how to use the library. So let's go and look at what it looks like to test a shared library. I haven't actually run the tests for the whole pipeline yet, I acknowledge that. We'll spend that time waiting on a test run on the shared library since that shouldn't be more interesting. So here we have a pipeline shared library. We've got a textual resource. We have a regular groovy class in the regular source, com, my company path. We have a couple global things in the vars folder. And then we've got some tests written for it all. Makefile driving everything and the magic that kicks off the framework, the Jenkins Spark framework and takes care of making everything detectable is powered by Maven here with a palm. At Jenkins World, somebody in the audience quickly threw together something with Gradle and said, yes, this works with Gradle as well. I have not done that myself and added Gradle-based examples, but- Did they do that like while you were talking, they was like, oh, let me do that. Somebody asked if it works with Gradle since most things that work with Maven- Exactly. And I said that I wasn't sure. And one or two questions later, Guy pipes up, it does work with Gradle. I just did it. That was pretty cool. It's clearly not terribly difficult, but I don't have an example yet. There is an open issue on the GitHub repo asking for Gradle examples. If anybody here is familiar and comfortable with Gradle and you wanna send a poll request that adds these same examples, but driven with Gradle instead of Maven, that would be, well, poll requests are happily accepted here. So let's look at this library. This is more or less the same thing as before, except we've got the pipeline for our application as a default pipeline.groovy, meaning instead of in our other application, instead of doing all this, we would just write default pipeline. And then now this application has nothing to maintain. It's all centralized into the shared library as one does, but if we do that, obviously the shared library is now responsible for making sure that the default pipeline works correctly. So the shared library has to write unit tests. And we've also got the deploy function in its own separate var called deployer to further contrive a example for every extension point of a shared library to prove that everything is testable. We have defined the deploy command as a constant in a real groovy class in the library. And finally, the message that we send it to Slack, we have said we're going to have a textual template for that over in the resources of our shared library. So that's all three kinds of extension points that a shared library can deliver. Can we unit test them without having to change around our shared library? Yes. So over here in the test folder, we've got default pipeline spec to test our default pipeline and deployer spec to test our deployer. What does that look like? More or less exactly the same thing. We still have the Slack is notified when tests fail, tests that we were looking at. It looks more or less exactly like what it was before. The only difference is that instead of Jenkinsfile.run, we are calling the step from our shared library.  Well, in the setup, we have to define that default pipeline step by loading a pipeline script for test. And we load our shared library variable. Now, default pipeline is going to behave just like it would in Jenkins. As before, we have to inject any environment variables or other variables that Jenkins would set since we aren't in Jenkins here. And then we also are going to stub the library resource step so that when we try to, well, we're being lazy and using the Spock idiom for match everything so that any time any bit of our code tries to get a library resource, it's going to get the string dummy message to mock out actually accessing our message template over there. And that's really it. We also, instead of Jenkinsfile, we've renamed it to default pipeline. Deployer spec is going to look more or less exactly the same. We have a deployer now instead of a Jenkinsfile. In the setup, we load that pipeline script for test. And then we can call the deployer with an argument and make assertions about what should have happened. Cool. So how that is it working? I guess I should show it actually working. Test our shared library. Notice it integrates nicely with Maven through the Surefire plugin running each specification one at a time, giving you the test result output. If we had failures, we would see failures, but we don't in our examples. That's good. And that was our test, our five unit tests against our shared library. So how does that work? Well, there is the Jenkins pipeline specification, as I mentioned, which is an extension to Spark. How do we get Spark to run? Well, we're using Maven to do two things. Bring in GroovyRuntimes, which we use, scroll, scroll, scroll, sorry, three things. Using GroovyRuntimes with the GMavenPlus plugin to compile and run that Groovy code. This requires specifying, in the case of the shared library, where our sources are so that they can be compiled and available for Jenkins Spock. We also need to add our non-code resource as a resource. And the other really cool thing that's going on here is all of those pipeline steps that are getting automatically mocked. They're only getting automatically mocked because the Jenkins plugin class files that are annotated as Jenkins extensions for each of those steps were on the class path when the unit test started because we added them as dependencies in our POM. What that means is that if my pipeline code uses the stage step, I have to add the pipeline stage step plugin as a dependency. If I don't do that, then I will get an error message when I run my tests, if that often. You'll see it's actually quite a helpful error message that guides you towards fixing the problem. The other really cool upshot of this is now you have a place to look at to see every plugin that must be present on a Jenkins master in order for your shared library code to be able to succeed. If that list is not complete, your unit tests will not be able to succeed. So now when somebody wonders, I configured the shared library, but what steps does it need? Do I have all the steps that this library is going to try to call? Well, now you have a dependency specification that those consumers can look at to make sure they've got everything. All right, so our test did not fail this time. Let's take a look at what happened. All right, we've got some errors. We see there's failures, but the cool thing is this error message, which is word wrapping. I'm going to zoom out just a little bit to try to stop the word wrap. Oh, okay, we'll keep it. So I'll just read this. So this was one of our unit tests. It failed and the error message is actually quite helpful. During a test, the pipeline step stage was called, but there was no mock for it. Now we have the power in Jenkins Spock to just create that mock and go on, but we choose not to because that forces you to identify all the dependencies of your pipeline code. That tells you is the name correct? Perhaps you know, perhaps you made a typo. Does the pipeline step have a descriptor with that name? Perhaps somebody's got a pipeline step that is called one thing, but available as another. Number three is probably the most common. Does the step come from a plugin? If so, is that plugin listed as a dependency in your POM.xml? When I add greater examples, we'll probably have to update this message to be a little more generic. And if not, you can, in your test code, explicitly say, I know that this pipeline step will exist, but it doesn't come from a plugin. In the case that you've got something crazy going on. And that is that. Now that we got this error message, we realize, oh, okay, yes, my code does depend on stage. I have to add as a dependency that my code depends on stage. And now, once again, the tests will pass. I think that is everything necessary to present, to spark any further useful discussion. I am just about at the 1030 that I promised I would stop talking at. So that's all that I have to say. Are there any questions? Or where do we want to go from here? If you're watching, rather than in the participant, feel free to ask questions in the Gitter channel. We'll give it a moment to see if anybody. I am not found in Gitter over here. I'll relay them. Anybody here who's on the participant? Well, I mean, we can start by saying this is a really cool use of a standard library to, and then extending it to do unit testing on Jenkins Pipelines. This is fantastic. I'm really excited about this. Well done. Well done, Klaus, you know, all of that. Okay, well, I guess, shortcomings of this, I don't bring it. You don't have to say that any of the shortcomings, we can just be positive about it, can't we? Opportunities for the community to get your opportunities data. We don't have Gradle examples, though allegedly it works with Gradle as well. That might make it more accessible to more places. We also don't address declarative pipeline. This is all for scripted. Declarative pipeline is a single scripted step that takes in data. So I don't spark framework test code, not data, but people that write pipelines want some ability to make assertions that the thing they're sending into their declarative pipeline is going to behave the way they expected. That is a very different problem than unit testing code, because somehow you need to be able to make assertions about what some other code engine will do with input data, side effects and all that, not just a return value. Declarative isn't directly executable, so we would need to bring the declarative engine in or something. I haven't figured out a path forward on that. Yeah, that might be pretty hairy, because declarative is so heavily dependent on the CPS execution context that you might not actually be able to run it. But I mean, the core of it is a groovy file that is basically run, you know, compiled down to CPS and run the same way shared library would run, it's a global variable internal, capital G, capital B, global variable internally. So you probably could find a way to pull it in and run it, but I'm not sure. Right, and the question is not how to do that, but how to offer some kind of pre-runtime confidence tool for declarative pipeline. Yeah, I mean, we've got validation already, but something, it'd be interesting to see how this could be mashed together with declarative validation to provide some level of confidence while allowing you to do much more thorough testing of the underlying shared libraries for anything complicated. Because within, as long as you're not jumping out to script blocks all the time in declarative, the expectation that the pipeline should run and all the steps that are defined in it is pretty solid, and that's one of the points of declarative is to make it declarative. But inevitably, sorry, go ahead. No, go ahead. No, yeah. Okay, inevitably people are gonna be at companies where someone writes a declarative pipeline that's 300 lines long and somebody else wants to assert that, all right, whatever they put in there, it is not going to try to deploy to production. It will always run unit tests. Yeah, so to be able to set preconditions to trigger the appropriate when conditions and that sort of thing. Yeah, that would be interesting. That would definitely be a good addition. That's definitely being thought about, but I don't have a path forward yet. And if you go to the GitHub repo and look at the issues, even the closed ones, there are a lot of interesting discussions there about how to use the library in various ways, how to achieve different things. A lot of cool things that you could take a look at if you wanted to read more about people trying to use this. I have two procedural questions. How is this licensed? Fantastic. How is this licensed? Version 2.0. The APL is always a good option in my opinion. I've just run into too many cops, Steven. The spoke weird licenses to not ask. Excuse me, the Jenkins Templing Engine is open source. I know, I know. Thanks for me having run into a spoke license and brought that up. The second question is, have you considered moving this into the Jenkins CI org on GitHub and so that it would be less of a single point of failure for, in the long term, it's... I have considered that. I would love to do that. I started reading the documentation for how to get something moved to Jenkins CI. And it's a non-zero number of steps. Drop me an email and I'll help you out. Yeah. It isn't, yeah, there's no ideological or legal or procedural reason not to do that. It's just, it's got a non-zero number of steps, which means I have to execute those steps at some point. And it's especially hairy when it's not a plugin because we have a whole process for plugins, but it doesn't quite fit for non-plugging. Drop me an email and I will put you in contact with the right people to help you out. Alrighty. I would say that, you know, last time we talked about the Jenkins Templing Engine, all of our libraries that we've developed for that, we test with Jenkins Spock and have had a good time implementing it and getting some test coverage on those things. So we appreciate your hard work. Yeah. And I, in my capacity as a CloudBees employee, have run into a couple of our customers using Jenkins Spock as well and recommended it to a number of others. So hopefully this will help with its adoption and we can finally have a canonical, blessed, maintained, updated, et cetera, test framework for Pipeline so that we don't have four or five divergent ones that are all kind of hidden away on their own without wide enough adoption or contribution to really be enough of an answer for enough people. So thank you very much for presenting Austin. I'm going to move on so that we can get through everybody else today. Can I throw one more? Okay. When you think regarding the Gradle example, I would try to take a look at that because Gradle is definitely a good alternative to build software. All right. That came in with a bit too much gain. Yeah. Austin, you may want to move your mic a little bit away from your mouth, but he was saying he's going to take a look at the Gradle, helping with Gradle examples. Thank you. One final thing, opportunity for community contribution. We don't have a solution for getting code coverage percent numbers out of these unit tests at the moment. And with that, I yield. That would be interesting. All right. I don't want to stop sharing my screen. You go to the presenting button. So next in the agenda is let me share the agenda again. Where's my button? No, I don't want to share my cat picture. I think she's adorable, but irrelevant to this meeting. Not irrelevant in general, Kitty. Better be sure to say that otherwise. Yeah, she's... Look up with claw marks, yeah. She's currently under the blanket in my bed right now. So she can't really hear anyway. Comprehend English, I think. I'm not sure. She may just choose not to a lot of the time. All right, so let's move on to our next agenda item. Marcin, am I pronouncing it right? Is it Marcin or Marcin? Marcin. Marcin. Marcin. I try to figure out how to pronounce other people's names accurately. So Marcin. On this group, who wanted to have a discussion on the ability to improve developer experience while working with Pipeline. So the floor is yours. Yeah, so I started that thread because it's somehow a continuation of my utterance at the BOF at Fozden as I'm somehow, as I explained on Githa channel, I was somehow frustrated having issues with quite the quite worse developer experience after migrating from job DSL as I... Can you hear me correctly about the... Yeah, sounds good. And as I understand, it's not the same as job DSL. The technology is different and I like some benefits of Jenkins Pipeline. I'd like to talk about the ability, about option. It is possible to do something. Some, if there are some areas which could be improved to have, for example, better code completion in IDE. Because currently it's some elements in the development are somehow problematic. And first of all, I wonder if I'm the only one who has that kind of problem. Because maybe I'm a developer and I'd like to, I'm specialized in automatic contesting in general, or it's my very specialization. And I'm somehow, I'd like to see, I'd like to see the framework that Austin showed before because it's somehow different that Pipeline unit that I was using before. So I hope to play with it and to get some other experience with that. However, there are some, there are more elements which are somehow problematic, such as code completion, code compilation, or the DSL was mentioning, even things like inclusion of shared libraries. Think it's, there's no standard how to do that because you can, in Jenkins, you can just add a shared library which is implicitly or explicitly included, loaded. However, in IDE, it's somehow problematic if you need to do some assembling, some other stuff. Therefore, on the one hand, I would like to ask you if it is, if I'm exaggerate that situation and do you think it's not a problem. The second thing is, do you see options which could be improved in various fields? And the third thing is about declarative and scripted pipeline because I think that declarative seems to be more promoted and more features such as ability to reply from given stage is available only from for the declarative pipeline. And maybe it's not worth to invest into writing better tools or better mechanisms for the scripted pipeline because declarative pipeline, which for me is more like a programming, it's something that will be promoted more and more and in the end, scripted pipeline will be deprecated. So if I may, I totally agree with you on the transition from job DSL's developer experience to pipelines. Job DSL has an amazing developer experience. I've actually tried on multiple occasions to hire Daniel Spielker, the maintainer and primary author of Job DSL and the guy who wrote pretty much all the demo experience related stuff, but he's not being available. It's very frustrating. He's awesome. I'm terrible at that stuff, which is part of the problem. Then on the declarative scripted thing, because that is a philosophical thing and then we'll move on to the more specific things. My vision, which is probably a general consensus amongst the developers working on pipeline these days and cloud views in general, is that the ideal scenario is, the Jenkins file is declarative, but if there's more you need to do that you can't do out of the box with just steps and declarative, pipe or shared libraries are exactly the way to extend because we're never killing scripted as the way to write shared libraries because there is definitely a need to be able to do more complex logic and conditional behavior and loops and various other things, then declarative will ever provide. I mean, there's things we need to improve in declarative that we just haven't had the chance because of other priorities from our day jobs, but that I'm hoping to get on our product manager to sign off on in the next few months, among other things to do things like adding the ability to pass a variable in some form between stages so you can capture the output of a shell step and reuse that in the next stage, but we still wanna keep declarative declarative, the structuredness aspect of it, which is not good for programming. Obviously, it's not programming. And I believe that it addresses maybe 80% 75, 80% of Jenkins file needs when combined with shared libraries. I'd like it to get closer to that 100%. It'll never entirely get there. And there's some things we can implement in declarative that are just really difficult to implement in scripted dimension stage restart. That's because declarative is structured because we know that anything that happens is within a stage and we know what has happened before that and what could happen afterwards. And the like, we can say, ah, this stage is an atomic unit. We can restart this. We don't have to save the program execution state and resume it, which is how a proprietary plugin from cloud use work, the checkpoints plugin works for either scripted or declarative. Actually, really, it only works in scripted declarative, it gets confused usually. But that is the nice feature.  And so there are ways we can do approximations of the same thing in pure scripted Jenkins file that we can do for declarative, but they're only approximations. They're all a lot more complicated to implement. They all have a lot bigger potential bug surface to it. And so if we can build features that, if it can take us a week to build a feature that is a little bit more complicated, that is exclusive to declarative Jenkins files, or a month and a half to build it for scripted, we're gonna build it for declarative. That's kind of why declarative is there. But again, we're not getting rid of scripted. We're not, in steps, et cetera, we'll always work in both. The execution in declarative is on top of scripted behind the scenes. It's only rare edge cases like Stage Restart where there's an opportunity presented by the structure of a declarative pipeline that is just not there and scripted that allows us to build new things. Obviously, I am very biased when it comes to declarative, not gonna lie, it's my baby, et cetera, but I've seen enough usage of scripted and declarative and to feel fairly confident that we've made the right call there. Now, in terms of the other things that you brought up here, code completion, IDE integration in general, yeah, we suck on that. I tried to pick up some work somebody did on the GDSL and you know, code completion for IntelliJ years ago, shortly after I joined five Bs and was no longer just a user and contributor to Jenkins was actually getting paid to work on Jenkins. And I could not figure out for the life me how to do it right. I think the right answer is that we need honest God, IntelliJ, Eclipse and VS Code plugins that can take advantage of the APIs on the Jenkins side that can expose things like global variables, like code completion, like declarer's validation in real time by talking to your Jenkins master and saying, okay, what steps are available here? Stop that, Austin, I can see you. Not necessarily requiring that, but I mean, we can't tell what all steps are available unless we know what the master has installed. We can't tell what global variable, what shared library stuff would be available, et cetera, et cetera. I think that was gonna add to that. I think that, you know, if you could took into that pipeline syntax API from your IDE to be able to ping it with, you know, I'm using the archive artifact step and have it return for you the data around what the available options are. Yeah, that's exactly the kind of thing I'm talking about. Pipeline syntax is generated off of resources that are in Jenkins plugin artifacts. You don't have to connect to a live Jenkins master to get that, you just have to know which plugins are on that Jenkins master. And what versions? Right, you need like a dependency specification or something. Yeah, it's one way or another without worrying about the exact mechanism, whether it's talking to a live Jenkins master or whether it's, there's some endpoint exposed from the Jenkins master that provides a specification of what's installed that you can download and configure in your IDE or you could just manually configure in the IDE to say here are the plugins and versions that I have installed or whatever it is. One way or another, an IDE plugin that knows what steps are available, what their arguments are, what the structure of a declarative pipeline can be and what's eligible to be used in what place would go a huge distance. I don't know, as I've said in multiple talks now, I have no idea how to write up one of those plugins. That's something where I have been periodically begging anybody I can find to see if there's anyone who knows anyone who could has experience with that kind of plugin. There is a BS code plugin for declarative validation, for example, it does talk to the ID, to the Jenkins master, but that's all it does. Well, the one thing to consider is that there's, we have the thing that generates that, the sort of the information for from your, but it's very minimal for your editor. If we actually got that working a little bit more, then rather than writing a plugin specifically for Jenkins files, we could have in the generics if there's anything that you can use this that might be a better, that might be easier to achieve then. Yeah, but I think the main point on in terms of ID integration is that we at CloudBees have not invested a lot in it and the community has not magically done it for us. And it comes up as an issue in what way, at Austin? I'm sorry to interrupt, but if I never interrupt, I'll never get to talk. Yeah, you raise your hand, that's fine. I have solved this a different way by shipping all of my pipeline code as resources, the byte code or text in a groovy plugin. I have regular code completion hooking off of the Java and groovy plugins for Eclipse for all of my extensions to Jenkins. I have submitted a proposal to talk about this at this year's Jenkins World. I can't show you anything now, but I have been working this problem. I just can't show you. All right, well then let's only have a talk sometimes. I'm going to plug in for things like auto, for things like more not, because there's things that matter to Jenkins, especially all of the stuff that's in pipeline syntax, all the validation that does not manifest in the code itself. Jenkins has to know to run the validator. So there is still a place for a lot more better experience with a plugin that's actually aware of that it's working with Jenkins extensions rather than just. So my way, what I have done is, as much as I could do with what was already there, but I don't want to say stop because there's totally still more to do. But I just wanted to grow that out there. That's cool. The reason why you can't show it is because it's internal. Yes, it is not open source to us. We are working on that. Basically the same dance that we had last year was, because yeah, it was around a year ago that I first saw Jenkins, the Jenkins Fock work, because HomeWay, you're still, yeah, HomeWay is a customer of CloudBees. So we heard about it through our support people's grapevine and they're like, I think your pipeline guys might want to see this. And then we started harassing, Kalske in particular started harassing Austin and HomeWay to open source it and to submit a talk for Jenkins World. So let me just. Let's just jump in here for a second. We have an administrator here. We're at five minutes till the hour. I think we probably want to move on to talking about Martin's question just for a minute. Yeah, I will, let me just throw something in here that will follow up on this subject at next meeting. Okay. So, I mean, I think the summary here for Martin is that yes, your concerns are completely valid and yeah, I mean, like, if you're having the problem, it's probably everyone having the problem. So input and help welcome and like, you seem uncertain as to whether or not there was a need there is. So let's continue to maybe also put this on the list for next time on things to talk about. Martin, or Martin. Martin, hello, yes, thank you. But I'll try to be quick. So this morning at the JSOC SIG meeting came a question from potential student regarding the advanced build this card plugin. So if I could share my screen, if you don't mind, do you see my screen? Let me stop sharing and present you there. Yes, we see. Okay. Yes. So the question came from the student and one of the users. So what I'm showing here is a pull request from to the Jenkins core. And it has been active for a while and we were trying to figure out why is the build this card or not discarding or how we could configure the build this card or to be more aggressive about discarding these builds in the multi branch pipeline. And more specifically one of the use cases, one of the users said he wants to keep the branches that are merged to production. He needs to keep them for audit purposes, but all the branches that are not merged in the end could be deleted. So I'm not a multi branch user. So it's like you're getting it from someone who has heard someone who has heard someone talk about it. So let me just see if I'm understanding. They want to treat merged branches as non-orphaned and preserve them indefinitely. They want to treat closed but unmerged branches as orphaned and have them go away. Is that right? I think so. And then probably more fine grained how many builds to keep for the branches that get archived but not removed. Does that sound in the right ballpark? Yeah, something like that. Unfortunately, I was trying to get the user to attend one of the meetings, but he cannot. So I think that's along those lines. He also said if he could set some flag in his own pipeline and this flag would say, this branch must be kept or at some point this branch can go away. Okay, so mainly we're talking about the branch we believe we're talking about the branch level rather than the build level. I think so. So that's orphaned item strategy rather than build discarder for what it's worth. And I'm not sure off the top of my head how well, how granular we can get with that if that's something that we can out of the box do right now or if it's something that we'll need to be implemented to be able to do more than just if it's open, keep it if it's closed, throw it away after some period of time. If you could start an email thread on the maybe on the signaling list if not to be directly with the user you were talking to about this, I'd love to follow up. Okay. Okay, I'll try to move the discussion to the email thread right now. It's in the JSOC proposal for the advanced build discard strategy plugin. Okay, I'll do that. Thank you very much. Thank you. Does anybody have anything else they want to talk about right now? All right, then you and share me instead. Again, not my cat. There we go. So there's my action item. For the next meeting all of CloudBees engineering and product org is going to be at an offsite in Spain during what would be our regular meeting time next month. So I was thinking we move it up a month and have it at same time, same day of the week but the first Wednesday. I'll send out an email and ping on Gitter to make sure but just wanted to bring that up in case anybody had thoughts right now. Otherwise, thank you all very much for attending. Thanks especially to Austin for presenting Jake and Spock and to Marisin for bringing up his questions and concerns and hopefully we can follow up on that usefully over by the time we have the next meeting and thanks as always Martin for keeping us looped in with what's going on over in the GSOC world. So thank you all very much and see you next time. Thanks. Thanks. See you.


All right, I show eight o'clock and folks hear me. Thumbs up, yes, no, maybe so. Cool, thank you. So welcome to the first support group conversation of one of many previous FGUs. Got a few slides to go through. We're going to do a tag team sort of an approach here. I'll introduce some of the agenda in the first slide, and then we'll break into various sections and move on forward. So as from a gender perspective, who's new? We got some self-managed and get lab haps. And then Tom A is going to give us an update on knowledge sharing progress. And then just a quick slide on Q3 and Q4 OKRs. So very excited. We've got a new support APEC manager starting November 12. So he's actually engaged already, and we're trying to get him some things to do before he even gets his first Mac. So we'll be welcoming him in a few weeks. And since our last meeting, a lot of new talent to the team across the globe listed them there. Hopefully we're all able to hear their introductions on the first Tuesdays. And if you haven't reached out and had a coffee chat with any of them, please do so. They've all started to make a big impact on the support team. So a lot of great talent had it there. So thanks to recruiting and all involved. A lot of folks on the support team doing interviews, the exec team for sponsoring offers, and et cetera. So thank you all. It was a very busy quarter in recruiting. From self-managed, Lee or Jan? Hi, everyone. You get me for three slides today. I will let Tom know when to progress. I wanted to just highlight a couple of things around self-managed right now. We're really focusing on diving into Prometheus. We need that. We need to leverage this. We learned that from a customer experience. We had a huge outage with a large customer based in Amia. And it took us four days to get through that. Prometheus was a huge help. And now we are evangelizing that like crazy. We really want that involved for any large distributed deployment. We've seen the light. The other big thing that I want to highlight, Kubernetes is still challenging.  It's been really helpful. So support needs support. Thank you. But Kubernetes still proves to be one of our bigger challenges as customers find those edges really fast around auto DevOps and Kubernetes-based deployments. So expect more from support there. And then lastly, we are sending support delegates out into the world in every way, shape, and form, trying to make sure that we are paying attention. So if you see someone from support asking to join a meeting or asking for links to something or clarity, we're just trying to make sure we understand what's happening and that we're building the right bridges. Tom, next one. One of the real cool things that we've been focusing on on the self-managed side has been performance. Performance engineering. We want to take GitLab to the next level. And we think that it's our responsibility to help deliver performance as a feature to customers. Making sure GitLab is fast. And working and helping with customers means that we get to see GitLab in the wild. This is just a quick little graph. We were playing around with a tool called Ruby Spy by Julia Evans. Shout out to her. Great tool. We're learning how to use these tools to trace and better manage the application as a whole. So really excited there. And on this slide, I'll update it afterwards. Will Chandler from our team wrote an S-Trace parser to help us move and get data out of S-Trace faster. So that's really awesome as well. So we are trying to drive towards more data-driven decisions and make it easier for us to see how GitLab works every piece all the way down to the system level. Awesome. Tom C, last one for me coming up here, if you would be so kind enough to change. I'm known for charts and graphs. And yesterday was my GitLab two-year anniversary. So I wanted to take this premium SLA graph and go two years. The bar at the bottom, that's two years of premium SLA. We still have not figured out the secret sauce. I'm sad to say. This is one of the biggest challenges we've had. There's still fluctuation. There's still ebbs and flows. But volatility has absolutely been reduced. We're doing a great job. Hires are proving to make an impact. And just seeing this chart over the last two years gives me hope that we're on the right track. But it is still one of our biggest challenges. So still diving in there. If you have thoughts, ideas, things you want to talk about, you can always find me. And we'll go from there. So I'm going to pass it over to Lyle. I saw a question in chat, but I'll save it till the end. On the .com side, we're full. We have all the agents that we plan to have. And that is fantastic. I don't know if there's very many places in GitLab where we're actually not hiring. So that's cool. Even better, the number of tickets we're getting to the size of our team is also good. We're feeling comfortable. But we're not quite 100% on our SLAs. And that's because we're focusing on learning to handle complex issues. So .com agents are quickly becoming much more developer focused. The tickets we're getting are harder CI questions and GitLab just moves fast. And our customers are really hungry. So just an illustrative example is our first ticket on the Maven Repositories feature was a week before the feature was officially launched. So that means that we have to know about things before we even know about things, which is cool. It's a cool problem to have. And that's sort of Lee alluded to building those bridges. That's part of the reason why we want to build those bridges is so that we can make sure that we're providing great support even before we release features. Another thing that we've noticed a lot is upgrades and renewals. People want to give us money. And that is a great thing. We're really happy that we're seeing lots of upgrades renewals request across the board into the right place and into the support queue. So we're really glad to have Kyla and Willis handling these. Yeah, so we've just kind of been, yeah. Sorry. I also wanted to mention that Git host is still a thing. It's still around.  Many are moving over to GitLab host. And so we are having some go to .com as well, John Woods. So if you click on that link, there's sort of an informal partnership that everyone set up. And a lot of times the reason that they move is because they have requirements for why they, where data can be stored. So we have some European customers for the debt that has to reside in Europe. So .com is just not viable. But we've also had a lot of issues with Git host as sort of like there's less support there and the team isn't as big. We've had issues with backups and upgrades, certificates, backups again. So we're looking forward to June definitely. I think that's it for me and I believe Tom A is next. Hi, everyone. I'm the second Tom in the support world. So for people who don't know me, I look after the support team in EMEA. So there are three of us, Lee Lyall and me at the moment and soon the new person in APAC. One of the things that I'm looking at this quarter is how support can share the knowledge we have. Support engineers, support agents, answering tickets in Zendesk, giving customers solutions. A lot of, most of that is private to the customer and it disappears into Zendesk, which is one of the few places in GitLab where information is hidden away. So wherever possible, we want to make that knowledge public. If a support engineer answers a question twice or three times, we shouldn't need to do that again. We should make it public and make it easy for a customer to find that information and that'll help us scale, helps customers self-serve, keeps them happier and saves us having to be like machines and repeat ourselves. We can actually dig into new exciting stuff. So I'm exploring this at the moment. Nothing active yet, nothing decided, but we are hoping to make progress on it very soon. There are two parts to the project. One is to find the place for us to publish stuff, which we have some ideas on. I've been talking to some other teams about how to do this. And the other part is how to help customers and us get Labr's search for this information. So there are some parallel efforts with some other teams, the docs team, Handbook, also looking for improved search solutions. So we're dovetailing with them to get a great search solution for when customers, for us, when customers are submitting a ticket, that they will be prompted and suggested solution, likely solutions based on the knowledge we've shared. So those two things, having definitely planning to have those up and running as soon as possible, certainly within Q4. And then after that, we want to be able to measure the success of this knowledge sharing. And there's various ways you can do this. Zendesk have some great research on this. The TLDR of it is really measuring how many people are actually using your knowledge base compared to the number of customers submitting tickets. And ideally, you want to be growing as a company, having more and more customers, but you don't want to constantly be linearly increasing the number of tickets that support agents have to deal with. So we will use some metrics to measure the success of that initiative. And there's a linked issue there, if anybody wants to comment or join in with that as we explore that and progress it. Thanks, Tom. Thanks, Lee. Thanks a lot. And from a wrap perspective, we've got the links there for our Q3 Retro, which includes the Good Bad Try, I think the latest Clint Eastwood movie. And then Q4, OKR's listed the link there as well. A lot of the Q4 was, a lot of the Q4 OKR's were referenced in this presentation around knowledge sharing and some of the process improvements, but also performance metrics, holding ourselves accountable to responsiveness to the customers. So that's it. Going into conversation mode. Let me look at the chat. Any last questions or conversations or quotes? Fun facts. So question from Reb on what is the value component? Yeah, we answered that a little bit lower. Reb's talking about in the graph that I had and the value component was percent of premium SLA achieved for that day. Excellent. Lyle, there's a couple of questions on Get Host. You wanna, what can sales help and why folks moving from Get Host to Get Host, Get Lab Host instead of .com? I think you probably addressed that in the deck, but any other comment? How sales can help Lee also address. So I mean, migrating into .com sooner is always great or migrating to self-hosted also great. So yeah, at least reach out and support managers on Slack and we can continue the conversation there, but essentially just the sooner you move, the sooner the less work I have to do on Get Host. Essentially. Always a key element. Yeah, and to just echo on that, if you are an account manager, account exec and you have Get Host customers, yeah, just feel free to jump in to support managers and we can always talk about your specific customers and try and make a plan. We want to do that. We want to help your customers explicitly yours, whoever you are out there. We wanna help your customers. Let's get them going and get them happy. Thanks Nadia for the call out there and referrals and for our hiring in APAC. We're eager to get some assistance out there for our new manager. Hopefully he will bring some references as well. Anything else? Speak now or forever old your Thursday. Okay, I'm not gonna verbalize it, but I'll go to five. I like this technique, Tom. Thank you everybody. Lee, have fun at the conference. Everybody have a great Thursday. What's left of it for the EMEA folks?


What's going on everyone Sam here late in sports car driven 22 top Star Wars chrome galaxy hobby 4 box break number 9 random letter style. Here's a look again at your random results as always you can find these on the website under the results tab as well as the link in chat Let's get going. Good luck here. Everybody again sketches will be random to everybody at the end. It's up SG Super Fracture Tuesday, you know a buddy In the house Lay it or Ghana and her Boosh disguise It's gonna be Pete got Jar Jar Binks 47 out of 50 going to J Ryan M. Congrats, buddy And lack of feet Sin it's why they put me on Tuesdays and Wednesdays with them to keep an eye. Yeah, that's what it is. I got to keep an eye on this kid Reven complaints that is the shadow of the dark lord. I got another auto. That's gonna be twilight Dorman Nice one there. Yes. I did base. Congratulations, dude. That's awesome. That's sick.  That's a galaxy gameplay Got going to the G that is gonna be Greedo Refractor and that's definitely That is big time Congratulations Echo going to the e-spot Sean's gonna drop you guys the link to Contenders optics basketball tiered random team style seven to go on that one Stop Dino. This is a top Star Wars chrome galaxy vintage Star Wars v9 on that one V9 is pop loop or pap loop Poe Dameron P. There you go. That's awesome. No smack Seven to go on that one guys break and soon wedge until he's in battle W Base and base right there. I was impressive ot3 Creatures of the Cantina it's gonna be C right there and base kind of atomic that is gonna be Uh eight out of 150 stormtroopers surveying the desert going to the s spot congrats s Base bv85 Boba a dark turn for Anakin Skywalker going to a and base aboard the bridge Base there's Yoda On the refractor. Yeah, this actually Ryan. There's this one Jar Jar Jar Jar's got cards in this That one's going to you Boba Fett battles the sarlak Uh non base or non refractor. There's a crosshair refractor and this the skywalkers Refractor hey, you're good ride. No worries man v13 of princess nisa life on Tatooine On the refractor l Chebacca's anguish going to the c spot It's wasn't bad There's Yoda ot9 The skywalker legacy going to t on the refractor and base Oh, we got wave uh 99 of 99 going to the g that is Greta Congrats on that g refractor bv98 Bask For b on the refractor and base on the boss number two more xr bunch xr just came in actually. Thank you guys Xr should be probably under 10 now. Yep down to 9 and 14 on xr And next break we are looking to fill is going to be contenders optic chrome or two contenders optic I don't know why I said chrome tenders optic Cheered random team style again every spot you purchase gets you two teams in the break That's got seven to go. So over halfway full On that one and then origins full case divisional at the end of the night Ben Kenobi Let's go mob get in 17 of 50 of 25 Boom going to my holiday. Congrats man. John carlo esposito That's so sick On the orange. There we go God, he's such a good villain and everything he played in every role. He has dude.  Let me double check That is ot five Yes, boba fat starship going to beat and refractor of a card game of chance This yeah John carlo esposito. I mean ever since breaking bad. It's been one of my favorite actors Rubble strike is r Bosch disguise beat And then he's like one of the villains in far cry six like he's he is the villain basically his like character is so cool There's yoda and luke skywalker Why There's v15 That is wicket in break tree village going to w luke skywalker assembles his lightsaber. That is l. That's a cool one, dude It's a really cool card Anakin skywalker on the refractor nice one there for the a spot base and base There's assuming boba ot two Uh, yep boba fat We quay for the w spot and up 10 stormtroopers assess their gear On the uh like x-fractor pattern nice one there seven of 10 going to the s spot. It's got s s is mark g congrats mark Nice one there Get that mag 40 mark. Yeah a bv 92 On the refractor bv 92 Uh tech Going t thin as well On the refractor going to the f spot. Uh ala sakura Refractor nice one there dark vader base wicket w warwick for the w spot Uh jedi outcast going to j Lord vader and his stormtroopers going to the l spot hold that up Ha got him again. Keep getting him, man So weak It's just sometimes sometimes you get got man Han Solo going to the h spot nice one there Six to go now on contender's optic. Thank you guys. What's up?  Oh get him out of here. He's gone get him out of here.  Boom I know anybody Oh, yeah, dina illegal dino medical droid going to m That's why I have a different thing every time we pull a g. I can't say going to the to that spot That's tuscan raider Got salacious b crumb on the refractor Like I literally had to uh The first like couple times I said it was like that doesn't sound right And that doesn't sound right the gg spot yoda on digba. That's to make my head, dude. That's to make my head. It's right This is getting out of hand Yeah, boosh on. Yeah. Yeah, get on that train boo trash Ooh darn vader 11 of 75 Going to the d spot Who's got d Caleb Caleb on the d spot. There you go, buddy. Nice vate nice vader. Look at that mag Caleb bv 99. Yeah, what are you three? It's all the same Surrounded by three year olds. I know they have donnie strapped in a high chair out there Wrapping tape around his head James covered in tape James picked up a spot in contenders optic james Thank you james again six to go on that well over halfway full Uh next break we need to show some love too as well as our origins full case Ranmar division style 16 boxes Is v seven v seven is the from gang going to tea Uh the dark lord and a new hope Oh, yeah, we magged that vader up. Oh, yeah, absolutely You better be watching and you better be like hey, thanks, sam Hey, sam. Thanks, man Hunter going to the h spot. Thank you for nothing Hey, sam. Thanks for hitting that one, man Appreciate it, dude. Come on, man Galaxy's greatest scoundrels going to jeep That's you Greatest scoundrels.  Looks salacious be crumb on girlfriend. You ever seen job with a hut? That's just mean rebel assault going to art Oh lord vader ready to ship No, we're fracking be crumb of like oh, that's forces, dude that little rat looking thing.  It looks like looks like there's some damage on there Oh, he's at the favorite employees meeting. That's probably true actually He's at the manager's meeting.  Oh, my name is Caleb. Oh, I'm a manager. Oh Oh, look at me. Oh, look at me. Oh, I'm Caleb. Oh, oh, I'm a manager. Oh That's that's that's what he says Uh, that's in the garage Darth Vader versus Obi-Wan Kenobi You guys are scheduled to work on purpose to miss the favorite employees meeting very true There's An enemy of the empire for a 50 going to a I don't know man. You gotta ask sam. I don't go to the trash meetings I've seen you there. No, you can do there I record all you guys. I see you there in a disguise rich wants me to record him There's Darth Vader And he walks under attack these clowns on the e That's what I do Look skywalker in action going to l I forget invited to me I always make sure it seemed like I have an inconvenience I got better things going on than to go to a meeting some measly meeting Uh bv 94 this week wet solo investigates S Chewbacca refractor Dean because I look like oscar in the trash meetings pop out of a trash can Yeah, that's the same desk We've got x-wing star fighter And katsu on yo going to the k spot who's got k That's gonna be andy h congrats andy Nice one there. What's up dan? Rebel assault Bounty hunters going to be A galaxy within grasp going to a such a cool card man. That might be my favorite card in the set I like it victor. It's actually it is actually a lot of fun green is Uh bv 90 bv 90 Is crosshair going to see that is 63 out of 99 star wars s So I'm dropping guys a link again to contenders optic tiered Six to go on that one. Like I said a well over halfway full Again, every spot you purchase gets you two spots in the break base That's the bunta eve classic Most is core football There's bv 93 of omega galaxy within grasp a Lack of fate lack of faith is good too, uh dan Teen always chasing big this Jq took the nationals sold out there Another 10 bucks tuesday spot came in That's a little more than a desk job I was gonna say it's the least desk job of all desk jobs for sure Absolutely Drop you guys a couple hundred thousand appreciate that dean. Let's go palpatine Refractor i'm rooting for dean too, man what I was going to say too is uh um I would hate to be leaf jersey manufacturer when dean hits beggin millions. Oh my god Just print them and send them cob vanth. I don't even put them into randoms anymore. Just start Just start hocking them hocking them to dean Not even randoms anymore. So everyone you get to going straight to dean Battlefront nice one there for b lack of faith That is cool that this is uh dan dubby dan wiseman said this is his favorite New hope wave that'd be sick wild I'll just buy a leaf leaf That's it Sean needs it man. There is v4 Uh, it's jesca mead and max rebo Princess lay out organa refractor p You know sketch man. That'd be sick Pre-ordering all our 20 cases of bummin and transcend it lando calrissi and you could probably do that if you want jeremy There there's gonna be a corner on the f1 market if jeremy wins, too I was so worried there's wave He's 15 of 99 his echo going to the e-spot Boba Fett. Oh god Streams done streams over Stop eating No, it's a redemption. Huh interesting See the base card wave refractor man with a mission p3 Interesting let's go see what that's gonna be. I'm not sure what this is gonna be once that guys p3 man with a mission That's just base Base card wave refractor just says man with a mission. So I'm assuming this is m right here Here I'll drop you guys to the random screen. This is it right here. This is p3 man with a mission Right there. So I'm assuming that's just m So that'll go to m right there. That is the base card wave refractor Yeah, I'm I'm joining you for us if I move I'm going off the grid to montana if I if I win the lottery I'm going straight to vegas That is bv88. Thank you for us. That's what I thought patrolling the cantina refractor for p the smuggler on solo We've got klatu for the k-spot, but I might have fun refractor Blow it all You hear about me on the news Florida, man bounty hunter answers calls And base Typer totem trash trash stinky guy Super star wars ads Uh x-wings in formation. Uh dang craig. That is that is a little bit of a hike That's like a three hour ride. Oh man. Have fun in fort laudy though Waterdale, that's my old stopping grounds right there. Oh, yeah wedge and tillies Refractor that's what I'm talking about Greg's going on his early spring break. That's what Greg's doing Always on the 12th Omega Refractor for oh, yeah, the weather's been beautiful the last few days Obi-Wan Kenobi and Boga Ah goes character. So if it's if it's moth gideon John Carlo Esposito goes to m for moth gideon Yeah, so it goes to the character on the card not the actor who signed it That's at st Didn't mean to intrude Two packs left I'll be let's get a sketch in these last two packs. Why not Luke Skywalker on end door Sean dropping you guys the link again to uh tiered random teams of contenders topic Greedo Darth Vader on the refractor nice one there And a still quick recap here guys I'll do it for the break. We've got a klatu that is Man with a mission going to m that's p3 Uh green to 99 as I believe crosshair kets the our ketsu onyo to 99 uh boba enemy of the empire four out of 50 going to the um Uh a spot. There's boba fat purple to 50 Greedo to 99 Atomic of stormtrooper surveying the desert so the eke dormant and charge our binks I it's not that bad kyle. I thought it was going to be worse than that There's to 10 is stormtrooper assess their gear seven of 10 We had 50 17 out of 25 moth gideon And dark vader 11 out of 75 That'll do it for the break guys. Thanks again for the fill next up. We got triple threads


Hi, this is Dr. Don. I want to take a few minutes and do a quick walkthrough of the lab four remix and report assignment. This is on correlation and regression modules. And here is in the lab manual, that remix page, giving you the link to RStudio Cloud. You know, the name is changing to Posit, still be the same as functionality, but it'll be Posit Cloud instead of RStudio Cloud. I've updated this web page. And there's some instructions there, you know, put your name at the top. You can rename the file if you like. This helps me out a little bit. And then always we have to load the libraries. And that'll be in your worksheet. And then there's some warmup exercises that I think you should go through. They're good. They'll help you with understanding and also maybe some ideas for running the actual assignment part. But I'm going to skip that. You can work through that. All the code is there. And we're going to go down to the first question. And it says for question one, we are working again with the World Happiness Report. The data file is in your data folder in your RStudio Cloud workspace. And here's the code for you can copy that. And then the question further says for the year 2005 only just one year, we want to find the correlation between perceptions of corruption. That's one variable. And then positive effect, another variable. And then we create a scatter plot to visualize this. And then it wants you to write up your ideas and conclusions about what this is. So, further, there's a couple of hints that are important. It says hint one, see code chunks nine through 11 and rehearse one lab four part four. And that gives you the code chunk. I think I actually put it into the rehearse worksheet. So that's where it came from. And then the second hint to add a filter to the data, see lab two, rehearse one graphing data in such an 8.2.5 code chunk 29. So you can navigate back to your lab two and get that. But I'll show you briefly how it works in this video. Then there's a second question. Still working World Happiness Report. And it says what has happened to log GDP per capita? That's the name of a new variable. And it says this is a measure of GDP, which it is stated in log terms instead of the normal scale. In the United States only. So we only want United States one country with year as our other variable. And when they're explained this relationship, write a scatter plot. And it said, again, here's a hint to add a filter. And we'll just build on what we did in question one. And then the third question is on a regression. It's based on rehearse two, which is about linear regression. And use this code chunk to load the data frame we created in rehearse two. And there is the data frame we need from Dr. DeVue, Saratoga.tex, run that code chunk. And then it gives you more help there. I want to know, is there a linear relationship between price and land value? And we'll have to do some editing, I imagine, to change out the variables. And then there's this code there, model, linear model, sales as a function of YouTube, data equal marketing. Now that's obviously not what we're going to use. You would put in there the real data. And then our two variables would be price as a function of little tilde there, a symbol is function of, you read it that way, land value. And then down here in the scatter plot the same thing, we would change out living area and price, excuse me, living area for land value, we could leave price where it is and just change out living area everywhere to land value. And that should be it. And then there's two more questions down at the bottom, actually three more that you should answer to, they don't require any coding, it's just those are think questions, but you should go through and answer those. So let's jump over to question one.


Hello everybody my name is John Smith and I am the boy that fell through the ice on January 19th of 2015. I was dead for over an hour and my mom came in and prayed and instantly I had a pulse. 16 days later from the time that I fell through the ice I walked out of the hospital completely healed. There is a movie called Breakthrough maybe you've seen it. There are also two books Breakthrough and Breakthrough to your miracle that the team and I have wrote regarding this amazing experience. I'm here today to just tell you a little bit more about me personally. I have traveled across the world. I have traveled across the country. I have spoken on news tours, movie tours, book tours. I've been all over the place but the real miracle behind this story is salvation. I was born on May 23rd 2000. I was born in Mexico City Guatemala. I do not know who my birth parents are. I was adopted at five months old by Brian and Joyce Smith and they brought me to St. Charles, Missouri. I was born, I say I was born and raised there but I was raised there in the same home with two loving parents. I had a private school education all throughout high school. I loved sports. My dad worked hard to provide all those training sessions everything. Lack of a better term I was a very spoiled kid but there was a lot going on within me that I was struggling with. Like I said I was adopted and that was very hard on me. I grew up in a predominantly white area and I remember one time when I was in kindergarten one of the kids asked why I was quote-unquote burnt or why I wasn't the same color as my parents and that really brought a lot of emotions up because I was wondering why am I different, why don't I look like my dad, why don't I look like my mom, my siblings and it was very hard for me and so the spirit of abandonment really just came over my life and I was just so frustrated on what was going on. When I reached about fifth grade I had fallen away from the Lord now keep in mind I was born and raised in the church. When the church doors were open I was there, I participated in the kid's zone and the royal rangers and all of the things the church camps led worship for the for the kid zone. When the church doors were open I was in the front row and I loved it but by the time I was in fifth grade I completely fallen away from all of this. I really felt that I had a calling young in my life to pursue ministry and by the time that I had reached this age I was done with the Lord, I was done with everything he had for me and I ran away. This led to an addiction of pornography, of me getting into things I shouldn't, substances at a very early age and it led to a road of destruction and falling away from the Lord. So when the accident happened a lot of people get this idea of me that I was this perfect kid, that I was this churchgoer and when the accident happened I came back to life they thought well you're John Smith, you're the second coming, you're the next Lazarus, you must be chasing after God, you must have this title, you must have this XYZ so on and so forth and that just wasn't the truth. The reality of it is if I would have passed away that day I would have gone to hell because I wasn't saved. I wasn't following what God had for me.  When I came out of the accident a lot of people assumed that my heart would have changed immediately, that was just not the case. I was still running from the Lord, I wanted nothing to do with the story of breakthrough or the story of the impossible. I did the news videos, I did the interviews, I did everything that they asked me to do but I did it with a bad attitude and it was very obvious that I didn't want to be there, that I didn't want to take place in it XYZ and so I remember it was about freshman year when we started discussing the book in the movie and I was still running away from the Lord, my heart was still not all in it and so when I did that it just kind of led me down this path of destruction. I was still doing the same things, abusing the same idols, worshiping the same idols, not living for Christ at all and I remember that I really loved the game of basketball and I truly believe that that was one of my big idols, it was something that I wanted to do for me and I didn't want to do for the kingdom and so when I did that I remember that I got hurt three times and when I got hurt three times it wasn't I believe that God was hurting me on purpose, I believe that God was getting my attention and every time that I got hurt I heard God's voice just say to me, John why are you running? Why are you running? And that really stuck with me and I ignored it, I kept ignoring it until finally I remember that because of the accident I had three major brain assaults and they said if I get one more concussion then I have to quit playing high school sports and I remember that I was playing that last game and I had another concussion and it ended my career, my dreams were all gone and I remember that when that all happened I just didn't know what to do with my life. I had a headache because I had a concussion, I remember being in my room and I remember just getting on my knees and being God, whatever you have for me I'll do and I'll do the best of my ability and ever since then has been an amazing journey of just seeing what God has done to the story of breakthrough and people think that I that I had an easy path going down this road and that just wasn't the truth. I still had to deal with the spirit of abandonment just really questioning God like you saved me then why can't this just be easy and I really believe that that just ties into what God is doing for all of us. You know he sacrificed his own son so that we could have a chance to chase after him and it's not an easy road it's not. I'm only 22 and I've done a lot of cool things but I still have the same struggles and the same battles every day the enemy just wants to tear my family to tear me down all of it and it's one of the biggest struggles and battles that I've ever fought but in the end I know God is going to still be on the throne and God is in complete control. I'm not a perfect man like I told you in the beginning I'm just a kid from St. Louis and that's what I wouldn't be known as what God has done in my life is truly a miracle but it's not who defines me what defines me is what God has done for me. So like I did that night all those years ago in my bedroom by myself I remember there was like this blue tent in the room it was really weird it was like a blue like a very light shade of blue and I didn't have it I didn't have anything in the room it was pitch black because my head was hurting and my room filled with this blue color and I remember just getting on my knees on the left side of my bed and I remember just raising my hands in the air and just saying God whatever you have for me I'll do and I'll do it to the best of my abilities and like I told you it was the best decision I ever made in my life and it's a simple prayer of saying God I'll do it I'll chase after you if you have me stay in this stage of life I'll stay there if you have me run forward and take a leap of faith I'll go but that is the best decision that I ever made and I encourage you to make that decision I encourage you to take that step of faith because what God has for you is so much better than we can ever imagine. I just became a father my son is um five months old and looking at his life and getting to see him I can only imagine the sacrifice that my mom went through and I'm human I can only imagine what God went through second pricing his only son and so if he's willing to do that I'm willing to sacrifice my life for whatever he has for me so if you wouldn't mind saying this with with me Dear Lord I thank you for today and I thank you for this opportunity at life I thank you for guiding me and loving me and Lord I give my life to you and like Pastor Jason always says Lord you drive and I'll ride my life is yours I give it to you today and I pledge my life to you it's in your name I pray amen


Okay you guys, what is going on? Welcome back to another video. In today's video, we are taking a little break from the AAF just for a moment, or for about 6 minutes and 59 seconds. We're going to watch a video by Highlight Heaven called NFL Knowing the Rules Moments. I've watched the first one, as you can see I watched the first 30 seconds. And, well, I guess I'm not even going to try and predict what I see because I'm most probably not going to know the rules. So let's get into it and see what happens. Check out Major Keith Zeke's for the best in sports apparel and workout accessories. They have free shipping worldwide for all orders over $150. Use discount code Jacob10 for an extra 10% off. Enjoy the video, and I'll see you there. Funnily enough, I've seen that happen in rugby a lot. You know, the winger will be down there catching the ball on the full, but if he's near the sideline, he'll actually put a foot in touch before he catches the ball so it's effectively out on the full. If the attacking team has kicked it outside of their 22 meter line, which probably means nothing to you guys, then if it goes out on the full, the ball actually goes back to where the kick was made, and it's the defences ball. So it's a very bad mistake to kick the ball out on the full. So yeah, similar. That puts the ball out of bounds, that's a penalty, and they'll bring it up to the court. You know, there's something inherently wrong with that rule. I bet Aaron Rodgers knew it. I bet he knew it. I bet he knew that rule. The rule and gift credit in this age, people don't know the rules, Randall Cobb knew the rule and took advantage of it. Left to its own devices that probably would have come to rest at the four yard run. It wasn't going out. No, it wasn't. It was going to hold up. What have we got here? Are you doing it again? It's not the same game, is it? See how he deliberately gets out of bounds. Make sure he's out.  No, it's not the same game. Same team. That's even better. I like that one. I don't know, his foot might have been up. Flute? Oh, it's the drop kick. It's the dropy. Ha ha, beautiful. I've seen that before. Belichick likes it. Thank God he got that egg. As soon as I mentioned I was a rugby player, as soon as I mentioned a drop kick, everyone meant to watch Doug Flutey do a drop kick and I did a while back. Classic moment. And then you've got Michael Dixon coming along this year doing restarts with drop kicks. I don't know about that. I wouldn't be restarting the ball with a drop kick because it can go haywire pretty easily. Cook will take the snap. He's going to back out. He's going to let the clock wind down. Six seconds left. Cook rolling around. He finally flags all over the place. The final seconds come off the clock and Sam Cook is still in the end zone with a ball before he finally steps out of bounds for a safety.  That two points will count and by roll there is no extension. So the game is over. It's a part of me that says you can almost take a safety. You're going to have to check. They're going to make it a point game. You're still going to have to check. What's going to happen here? Two of them down by one. They're in their own end zone fourth and 10. What kind of rule are they going to come up with there? What? I should probably stop talking that. Hang on. What? So they took a safety on purpose similar to the last one to give themselves a chance to... Do they get the ball back? If they have a safety... I don't actually know what happens after a safety. You sure that wasn't just a mistake? Woo! What is happening here? Four seconds to go. It's a restart, is it? What? I don't get it. Damn, he had the distance. Oh no, here we go. What's going to happen here? Nothing, nothing.  Free kick. When do you get a free kick in football? The NFL has a little-known rule called the fair catch free kick which allows a team to fair catch a punt and then line up and kick the ball on the next plate. Without the defense able to rush and block the kick. Okay. So we call the fair catch at his own 40-yard line. Usually you take the run, but it's only four seconds to go, so they take the kick instead. And no one's allowed to block it or do anything because it's a fair catch. Huh. Here we go again. Right, only when the score... Only when the clock is nearly up would they take it. Get it? Tell me you got it. Ah, see that would be an opportunity to get like the longest field goal in NFL history, wouldn't it? Off of a fair catch. Gotcha. A fair catch with like less than 10 seconds to go on the clock is the only way that would happen. From 69 yards out, it's just that short. What have we got here? Is this Dixon? No, it's not. You would be so annoyed if a team took a safety, wouldn't you? They have five points ahead just like that last one, and they take a safety. What absolute pussies. What have we got here? Let me watch that again. It comes from the 50. Is it though? Yeah, a touch back is only when it goes fully past the dead ball line, right? Not when it just crosses the end zone. So why didn't they continue watching? You never know where the ball is going to bounce. People following him were officials. Bailey could pick it up. Boy, that is heads-up football by Bailey. I guarantee you he was the only one on the field that knew what was going on. Bailey's 28. Look at the bounce. That's the red bounce. Why are those? They saw it not go out. Nobody is even looking at him. My heart's walking off. He unstaps his helmet. He's got no idea. You see the officials going by? They were the only ones with him. Maybe a couple rounds. Oh, man. Okay. Jeez. I've got to say, man, I've got to say that was one of the hardest videos for me to follow ever. And I don't know what kind of version you're going to see, what kind of final version you're going to see of this video, but I have repeated myself. I have stopped and started this video so many times because I've literally just not even known what I'm talking about, and I've just had to stop myself and start again. This video is seven minutes long.  But anyways, guys, without further ado, if you have, oh, we've got a live game here. Oh, I won't watch that. Atlanta's winning, which is good. Atlanta's the team that I'm going to support this year, but I'll wait for the highlights to do that one. Anyways, guys, as always, if you liked this video, hit the like button. If you want to subscribe, even better, and I'll see you in the next one. Peace out.


Hello and welcome to this overview of security features present in the STM32 U5. The STM32 U575 and U585 family of devices is designed with a comprehensive set of security features, some of which are based on standard ARM trust-one technology. These security features simplify the process of evaluating IoT devices against security standards. They also significantly reduce the cost and complexity of software development for OEM and third-party developers by facilitating reuse, improving interoperability and minimizing API fragmentation. This module describes the following key security features. Secure boot, thanks to the unique boot entry and hypertext area or HTTP features. Improved resource isolation using trust-one and privileged mode extended to secureable IOs, memories and peripherals. Enhanced lifecycle management with readout protection or RDP. It includes debug protection and optional password-based RDP regressions. Dual developer firmware distribution scheme using trust-one on the fly decryption and RDP 0.5. On the fly decryption of encrypted images stored in external flash memory with associated secure firmware installation. In other modules you find the following information. Enhanced secure storage, cryptographic acceleration including side-channel protection when manipulating secrets, active temper and protection against temperature, voltage and frequency attacks. Secure firmware installation, certification CC level 3 and PA say level 3. This line summarizes the boot options when trust-one is enabled. When boot log equals 1, the boot address is unique and defined by secure user option segboogadd0 whatever the other parameters. When RSS CMDR is non-null and boot log equals 0, boot in root security services or RSS is performed. And when RDP is greater than 0, the boot code must be located in a secure area. When trust-one is disabled, only the center of the table is relevant with non-secure nsbootadd0 replacing segbootadd0 and non-secure nsbootadd1 replacing the RSS fixed address. In embedded flash there are two write protection areas per bank controlled by non-volatile configuration bits. These bits cannot be modified when the corresponding unlock configuration bit is 0. Unlock bits can be set only when regressing from RDP level 1 to level 0. When trust-one is enabled in the device, embedded flash features the following protections. One secure area per user flash bank, defined with secure non-volatile user option bytes. Default programming is all secure. One secure hide protection or HDP area per bank, strictly hidden after boot by application. 8 kilobytes user pages on the fly defined by the application as secure using volatile secure registers. Default configuration out of reset is non-secure. Additionally, each 8 kilobytes user page can be defined on the fly as privileged only using volatile privileged registers. When a page is defined secure, only secure applications can change this property. When trust-one is enabled, the secure world can be used to protect critical code against intentional or unintentional tampering from the more exposed code running in the non-secure world. Whether trust-one is enabled or not, the cortex privileged mode can be used to protect critical code or data against intentional or unintentional tampering from the more exposed unprivileged code. These resource isolation features were instrumental to obtain the CCIP level 3 and PSA level 3 certification. CCIP stands for security evaluation standard for IoT platforms and PSA stands for platform security architecture. On top of the ARMv8-M trust-one security extension in Cortex-M33, the device has embedded complementary security features called the Global Trust-one Controller or GTCC that reinforce in a flexible way the isolation between respectively secure non-secure worlds and privileged unprivileged worlds. GTCC protects peripherals using registers in the Trust-one Security Controller or TZSC. It protects memories using the Memory Protection Controller Block Based or MPCBB and the TZSC registers. GTCC can protect against non-secure and optionally unprivileged transactions initiated by masters other than the Cortex-M33. Note that some peripherals do not require GTCC to offer secure or privileged protection because they natively trust-one aware and privileged aware. The Device Life Cycle is managed by the Readout Protection Option Byte or RDP. This RDP mechanism is a hardware feature that controls the access to the device debug, test and provisioned secrets as summarized in this table. The new features around unlocking keys are described in the following slide. Password key-based RDP regressions are available through the debug interface or via the system bootloader. They're ideal for customers that don't want to irreversibly log devices. Two 64-bit keys are defined in embedded flash to independently protect secure OEM1 and non-secure OEM2 application codes as shown. One usage of this is described in the dual developer firmware distribution scheme slide. Note that unlocking the device with a password is only possible once per power cycle. OEM1 key can always be modified when RDP is zero. It can be changed when RDP is 0.5 or 1 if OEM1 log equals zero. OEM2 key can always be modified when RDP is zero or 0.5. It can be changed when RDP is 1 if OEM2 log equals zero. Through the debug interface, a 32-bit device's specific quantity can be read to compute device-specific passwords. This method doesn't apply if IDP level is 2 and OEM2 log equals zero. Getting the password will never compromise data confidentiality. It only allows to regress the RDP protection. The device supports the STM32 dual developer firmware distribution scheme. In the single developer scheme, one OEM develops secure and non-secure applications. Both applications must be protected using RDP level 1 or RDP level 2. In the dual developer scheme, the first OEM develops the secure application. It's associated non-secure callable library and provides a predefined linker file to the second OEM that develops the non-secure application. In the dual developer scheme, the secure application must be protected using RDP level 0.5 after installation. The final non-secure application must be protected using RDP level 1 or RDP level 2. The OTF deck module decrypts on-the-fly read-only information encrypted in external SPI flash. AES 128-bit cipher encounter mode is used to achieve the lowest possible latency. Four independent and non-overlapping encrypted regions can be defined. For each region, an additional layer of protection can be added on top of the standard AES encryption algorithm requiring the encryption to be done on-chip. When such enhanced protection is selected, only instructions can be stored in the region. OTF deck also supports an encryption mode available when no decryption is ongoing. All key registers are write-only and automatically erased in the case of tempers or RDP regression. OTF deck is a trust-owner-ware peripheral. All writes to its registers must be secure when security is activated in the product by setting TZEN. When privbit is set in OTF deck, only privileged accesses are granted when accessing most of the OTF deck registers. OTF deck analyzes all AHB read transfers on the associated AHB bus. If the read request is within one of the four regions programmed, the control logic triggers a keystream computation based on the AES algorithm encounter mode. This keystream is then used to decrypt the data present on the fly in the read transfer from the OCTO SPI AHB master. Any access outside the enabled OTF deck regions belongs to a non-encrypted region. As OTF deck is used in conjunction with OCTO SPI, it's mandatory to access the flash memory using the memory mapped mode of the flash controller. The OTF deck can assert an interrupt to their NVIC for three possible causes. Security error, key error, execute only or execute while encryption error. Each of these errors has a dedicated flag and an interrupt enabled bit. Secure firmware install or SFI is a global solution for this STM32 series of microcontrollers, allowing secure and counted installation of OEM firmware in untrusted production environments such as an OEM contract manufacturer. When external flash memory is targeted by SFI, the OEM firmware code must be encrypted with a dedicated AES key. This key can be common to a family of products with OEM tools performing the encryption or unique per device with the firmware encrypted inside the device. On-chip encryption is mandatory when OTF deck enhanced encryption is selected. For more information, please refer to application node AN4992 for secure firmware install solutions. Thank you for having attended this presentation. You can now refer to the presentations that detail the operation of the STM32U5 security modules. Symmetric cryptography, asymmetric cryptography, hash and random number generation, enhanced anti-tamper, enhanced key storage.


Hi everyone, Joe for jaskiescasebrakes.com coming at you with a random number block randomizer for these following teams right here and that unlocks Pick your team five of Panini three and two baseball. So that's the instructions on On those redemptions right there if there's any I think all the cards should be numbered But if there's any non numbered cards will randomize it to this group right here big thanks to this group Appreciate you there. The numbers right there. Let's roll it and randomize names and numbers three and a three sixth the hard way one two three four five and six We got mark down to Jackson and three and a three sixth the hard way for the numbers one two three four five and six One down to six Remember zero gets any and all redemptions for those following teams including one-of-one redemptions Mark you'll still get live one of ones Nicole has three Steve has four Nicole eight Steve with two Jackson with nine Steve with five Ed with seven Barry with zero and Jackson with six Sort numerically And so once again, it's a serial number break only involving these teams right here There you go. All right. I'll see you in the next video for the break itself. Jasper's case breaks calm. Bye. Bye