Welcome, everyone. This is the introduction to Jenkins 2.277.1, the new Jenkins long-term support release. We're delighted to be here with you. Thanks very much for joining us. This is being recorded, so it will be available separately later as well. I'm Mark Waite, joined by Oleg Nanashiv, and together we'll be presenting much of the material here, then in addition to those, the presentation part, we've asked three of the key developers involved in these changes to join us for a panel discussion, where we'll do question and answer, letting us ask them questions, gain insights into their experience and what they learned from taking a product used by 250,000 installations from previous technologies to newer technologies. We're thankful for Jesse Glick, for Felix Keroga, and for Tim Giacome, each joining us as panelists. Thanks very, very much for being with us. Now, by way of agenda, we're going to do these welcomes, and then we'll talk through the introduction to Jenkins 2.277.1, including things related to the user interface, how we improve the core, and then we will shift into a panel discussion where we'll invite questions from the audience and questions from Oleg, from me and from others, to gain insights into what it meant to make these changes, how they were verified, what sorts of experiences there were. We encourage you during that phase to ask questions of our panel as well. By way of reminder, during the meetup, it's best if you use Zoom's Q&A feature rather than chat. The Q&A feature lets us manage the questions more effectively, you'll find the Q&A button on your Zoom user interface. Now, we will reach a point in the meeting where we will turn off the recording, and after having turned off the recording, we'll actually grant voice to everyone so that you can come on and ask questions of our panelists separately. We like to do that because we want the recording to be have had the benefit of careful vetting by us as moderators, but we want you to have the facility to ask questions at the end if you'd like. And after the meetup, the Jenkins mailing lists are a great place to ask questions, and at the conclusion, we'll ask you to submit your answers to this feedback form, helping us better understand which things work well and which don't work as well for Jenkins meetups. We're so glad that you're with us and looking forward to a great session today. So Oleg, you want to go ahead. Okay, so I will do a brief summary of what was introduced in the recent LCS release. 2.277.1, this is a new baseline, we released the first LCS release in this baseline last week, and many of you have probably installed it. But still, we would like to discuss what's inside and talk about how to upgrade and what potential obstacles you may experience. Next slide. Just quick summary, what is Jenkins LCS? Jenkins LCS is called long term support, though historically we rather use stable release term when we discussed this LCS, because LCS release is selected every 12 weeks. So it's not a long term support, something like several years. So it's rather a stabilization release. And when we select new baseline, we have three releases every four weeks with backports and security fixes. Sometimes if we need to release additional releases, or we can maintain the release line all longer. But we normally expect the user to stop with the new baseline after 12 weeks, or eventually when they're ready. First, the process is coordinated by the Jenkins release team, and by Jenkins release officer, a team who's also on the call. And the team is working on preparing backpours, preparing challenge logs, and preparing upgrade guidelines for each release. Next slide, please. So, if you're Jenkins, next slide. Thank you. So, yeah, what do you get as a user? Firstly, you get all packages. So it's a Word file. It's a installers for different platforms including Windows multiple Linux versions and those docker packages, which you can use for docker and Kubernetes deployments, deployments in other container environments. So there are packages which are not maintained by the Jenkins project directly, but maintained by other communities, for example, free BSD, Gantt, Macos, OpenBSD. We don't distribute these packages on our own, but they are being released by other communities. And yes, you get to change logs and you get upgrade guidelines, which are specific to the LCS releases. You can use it when you prepare to upgrade to the new versions. You can go through changing logs between your current Jenkins LCS version and the one you want to install. And you can see all major changes and all steps you need to perform to do the upgrade. So, let's go to the next slide. So, for 2.277.1, it's basically a weekly release with some backpacks. So the previous brain line was 263. And in this version we introduced quite a lot of changes, but actually in 2.77 we introduced a lot more and some of these changes are breaking ones. The release is quite stable and it includes bug fixes which have been released since the baseline selection. So we selected this baseline six weeks ago and over six weeks we processed all the repressions which have been reported for weekly releases, we reported fixes, and when you install a CS release, these fixes are already included. So the release should be quite stable. Next slide. So, if you want to find a change log, you can go to the URL provided on the page. And if you go to this page, you will see some interesting details. There is some animation on this slide. Okay, we can do like that. So you can see that the current community ratings are not exactly great. So we have 124 successful deployments, but some users reported different regressions. So you can see that approximately 30% of upgraded terms experienced some issues. And it's quite a high number. So it would be nice to understand what happened. And, yeah, let's go to the next slide then. Okay. Yeah, so yes, there are breaking changes. And actually that is quite a number of them. It includes. Could you please go to the next slide. Yeah, thank you. So, in this release, we started at the recent technical depth we had in the Jenkins core. So there was a lot of changes related to visualization and dependencies. This is the most significant update of SG security to spring security replacement of all the extreme for by upstream version maintained by the extreme community. And we have the awesome library and actually we updated a lot of other dependencies inside the weekly baseline between these releases we have enabled to depend upon so actually, there is a lot of library updates here and there. And these are main dependency changes. Also, there was major changes related to configuration forms and forms in Jenkins in general. So what we call the table studies improvement for better accessibility. And yeah, this is also breaking change. Later we will discuss these changes in details. I just summarized them and glance. So, for those who use system properties that there were several system properties which were placed by new names. So no Hudson now it's Jenkins. In addition to that we had a few improvements. So, for example, plugin manager got a lot of improvements where you get available pay page so it lists plugins much faster. So that was synchronously. Then, now you can specify a reason for preparing to shut down. There is new color palette, which is a continuation of your UX improvements, which you may have seen in previous releases. And also there is a lot of performance improvements and events here and there. So the full change lock is much longer that one would present, but I just wanted to list key highlights. And, yeah, I think that we should just talk about the details, especially about the breaking changes. Mark, would you like to take over. The key components that we see here. The first piece for me is this user interface improvement story. And we have to offer sincere thanks to Josh Soroff who started the, the poll request. Well over a year ago to Felix Kerrigo who has been a major leader in in implementing it Joseph Bergen for his design work on it. And Tim Jacome for amazing fixes in all sorts of places. Daniel Beck for some really good testing and evaluation, and many, many plugin maintainers. Thank you. Thank you. This has been an amazing effort to bring us this new set of UI improvements. As we see the old UI before to 277.1 was laid out with HTML table markup, and that meant even on a wide screen so this screenshot that you see here is a 1280 pixel wide screen. You can see the scroll bar at the bottom, and notice that the fields are truncated over there on the right hand side. It just didn't feel like a reasonable use when my nice wide monitor doesn't fit the whole form that I need to edit. Thanks to these changes that have been made. Now, the fields fit inside the page. Okay, that's that's already a nice. There are also hints with dashed lines along the left hand edge edge that helped me see which things are grouped together previously I wrestled with hey how does this work and where does which thing does this apply to and that doesn't apply to you, and no horizontal scroll bar. So, those kind of things are significant improvements to the experience for someone editing in forms. Seven core pull requests, 40 plugin releases 40 plus plugin releases 14 weekly core releases to get here. 56 issues resolved. And yes, there are 15 issues still open. Well, a live demo as well and oh like I think that's, that's kind of a fun exercise let's take a look at my Jenkins on my live environment. So, here is my Jenkins installation and if I go to manage Jenkins note this is 263.4 so the previous long term support release manage Jenkins and I'm going to click configure system. And my screen is quite wide, and yet we're going to see when configure system arrives that I'll likely get a scroll bar lucky me. Meanwhile, while that is loading. We're going to do the same exercise with Jenkins 2.277.1 manage Jenkins configure system. So, here we have 277.1 wide screen and already I've got a horizontal scroll bar. And as we go down the UI is Oh look, picking the credential is really hard to do because that the pick list is actually off screen. Those kind of things made the UI more difficult for administrators in Jenkins versions prior to 277.1. Look, everything fits and yes I've got these nice little hints over here on the left that tell me what's going on, which thing I'm grouped with and how. Thank you very much Felix, Josh, Tim. Thank you all of you for doing the work to give us a better UI. However, you can open this configuration page, even on the mobile screen, and actually it will look quite good. And, and all like you make a very good point that it's quite a treat that now my narrow devices. Okay, I've got a Chromebook I use I've got my phone that I use. I can actually do better have a better experience on those narrower screens on many different screen sizes than I could before. I can barely imagine that somebody would manage configurations from mobile screens, but in practice you can do it. Right, exactly. So now the question is how do you get there. And, and this part we're going to reinforce multiple times today you get there by reading the upgrade guide. We've intentionally described in it things that may need your attention. So many Jenkins releases on LTS. You may have ignored the upgrade guide this is not one of those places read the upgrade guide. Second step, remove unused plugins before you do the upgrade. Many times older plugins will cause bumps and bruises that you don't want to experience. So if you realize hey I'm not using this plugin. This upgrade is a great time to choose to remove that plugin from your installation. Now, then, even before you upgrade to Jenkins 2.277.1 upgrade your plugins. Now you may be accustomed to doing Jenkins upgrades without upgrading plugins but because of the breaking changes inside 2.277.1. It's important that you upgrade your plugins. You do them before because there are many plugins that can be upgraded even without upgrading to Jenkins 277.1, and you get, you get that newer version. If you do the upgrade to Jenkins 277.2.277.1, then afterwards you again do the update of your plugins because there are some plugins that must be that are that are not available for 263. So you need to get 277 and then upgrade again so remember that's two plugin updates that you need to do. Now, Oleg, do you want to take on core component improvements or do you want to introduce it to Jesse, if Jesse is interested. Okay, Jesse, do you want to be voice. I can't actually talk about the ASM update but I can talk about these two slides so was listed as Jenkins enhancement proposal number 227. And this the idea here was that since pretty early days in the Jenkins project actually going back to Hudson days, it had been using this library called Seji security. I hope I'm pronouncing that right. And that was sort of an old Java based security framework. And Jenkins was using a lot of the API is defined in that framework to handle every aspect of login and authentication. So basically anything that you would configure under the security realm part of the configure security of global security screen in Jenkins. So that would be built in user database, LDAP, different kinds of SSO systems, active directory, all of those authentication plugins are all using this API. And a lot of other plugins were also using this API to pick up information about who the logged in user is and what kinds of groups they were assigned to LDAP groups, that sort of thing. And this all worked. But basically, we were stuck on this old library. And years and years ago, that library was totally rewritten. And it was, I won't say totally rewritten, but it was largely revised. And the revised version became known as spring security version 2.0. And that was sort of broad under the aegis of the spring project with a lot of other libraries. And by the time we came to this work, that library was on spring security version five. So you can imagine that there were a bunch of other major refactorings in three, four and five after that point. So we were using this very old library. We didn't really want to be using it. We would rather be using an official upstream version of all of these things to make sure we're getting all of the latest fixes, especially for something as important as user authentication. Unfortunately, not only did the rewrite to spring security change the Java packages, but it introduced a lot of other incompatible changes to the library. So it wasn't an option to just replace one line in Jenkins and say, yes, please use the new one, change this version number, and everything would be fine. Not only did we have to change hundreds of files in Jenkins Core to refer to new package names, but a bunch of other things needed to be changed as well. And it turned out that dozens, maybe hundreds of plugins were referring to the old library under the original package names and making assumptions about how the old library worked. So I'm not sure how much detail you want me to go into now, but basically this involved a pretty big patch to Jenkins Core to introduce the new security framework, keep some stubs in place for the old one without actually bundling the old library, just creating a facade that would let plugins that were still built against older versions of Jenkins continue to work the same way with only a very, very few exceptions. And so this landed in Jenkins 2.266, which means that it appears in this LTS line for the first time now. So I think that's, yep. Excellent. Thank you, Jesse. So this is my chance to, would you be willing to be the voice on this particular slide again, just to remind people what should they be doing? Upgrade plugins, yes. There is a list of plugins affected by this change that we know about. Try to best keep it up to date. We rely on community contributions to notify people, notify us and everyone else about when particular changes are accepted and released and so on. As far as I know, all of the changes needed for, they're actually required for plugins to work after this change have been released, meaning that you can, meaning the updating plugins before the Jenkins Core upgrade work. So they've not just been released, but they've been released in versions that are compatible with the previous LTS line. There's one exception, which is the CAS plugin, which is a sort of not frequently used single sign-on authentication plugin. That one, for technical reasons, we couldn't do that. And so for that case, you actually have to update the plugin at the same time that you update Jenkins Core in order to be able to continue to log in. So now, if, Jesse, if the user made the mistake of not updating their plugins before they did the upgrade to Jenkins 2.277.1, is there a risk that in some configurations they might be locked out? Yes, definitely. So if you, for example, if you were using an older version of the LDAP plugin, more than a few months old, I think it was 1.24, maybe, or 1.25, that the very basic compatibility fix went in, the minimum compatibility. So if you're using an old version of the LDAP plugin, you haven't upgraded in a while, and you just went and upgraded Jenkins Core without touching that, then after the upgrade, you would get all sorts of errors the moment you tried to log in. And that's especially a problem for a security realm plugin, because you need to be logged in as an administrator in order to update from the GUI. So that's why we really emphasize you should accept all upgrades before you do the upgrade to make sure you don't have this kind of lockout situation. If you get into that, you have to go into the Jenkins home directory and shut off internet access to your server, go into the config.xml file, and turn off security temporarily, log in as admin, do the update, and then undo all of that. So it's possible. It's just a bother.  In the past, it wasn't always that way. This is somewhat distinctive because of the breaking changes in this one. So, Jesse, on the next topic, extreme unfork, would you be willing to share some further insights there? Sure. So this was another Jenkins enhancement proposal, kind of along the same sort of lines that we wanted to be using an up-to-date standard version of a library. In this case, extreme is a sort of an alternative to Java serialization. It follows a similar model to Java serialization, but it reads and writes XML. And basically everything in Jenkins that has any kind of stored configuration, any kind of settings, as well as metadata about builds, definitions of jobs, all this stuff is all stored in XML files using this library. So it's pretty central. And unfortunately, we were using a fork of this library that, I guess, goes to K-Fork way back in the midst of history to add a few customizations here and there. And the discrepancies started growing. And we had been making an attempt to pull in upstream changes from official extreme releases and merge those with our patches to it. So we had half a dozen little changes to extreme or something for Jenkins use. But the patch was falling out of date and it was really painful to maintain those things. It would take somebody a day to go through and analyze what needed to be done when we do the update. And so the result was we weren't updating it. And worse, one of those patches was actually the result of sort of a misunderstanding of how extreme is supposed to be used. So we were using an annotation feature that was convenient and was used in a handful of places in Jenkins core and a few plugins. And it was nice. But it had a prerequisite about the threading architecture of how you use this library that did not match how Jenkins actually worked. And we had tried to work around it with some patches in the library. But when we offered those to the library maintainer, he said, no, no, no, this is not how you're supposed to be using it. No chance I'm taking these. So we were a little bit stuck with that. So as part of this work, it was a little bit easier, certainly than the 227 spring security work. But we did need to basically undo that patch, throw away that facility and change some codes in both Jenkins core and a few plugins that relied on that assumption, basically make it work with the official version of the library cleanly. So that also cue the next slide. And require some updates. In this case, not quite so critical, because I think nothing is going to block you from doing the update as an admin after you upgrade, but you might see a bunch of stuff broken before that. You could have failing builds. I'm not sure what all could break. So that's being on the safe side. Thank you, Jesse. And thanks for your work on the Jenkins enhancement proposals and what you've done there. Much appreciated. So the ASM upgrade is one that I've been aware of. ASM is a bytecode manipulation library that is used in the product in various ways. In this particular case, the example was that we brought in a new version of the ASM bytecode library and the token macro plugin had to be updated to adapt to that new one. If you don't have the latest version of token macro, and you can install it still on 2.263, but if you don't have the latest version, when you upgrade, you may get messages and warnings and failures that are described in the upgrade guide. But this is our way of saying, please, this one has nothing to do with breaking Jenkins XML reader right. But what should you do? Read the upgrade guide, remove unused plugins, update your plugins before release, before they upgrade to Jenkins, upgrade Jenkins, update your plugins again. So why plugin upgrades? Because we've made breaking user interface changes. We've made breaking security framework changes, breaking serialization changes, and breaking bytecode changes. You need current versions of plugins. This is different than many releases, but absolutely worth it. So this is where we switch to the panel discussion, and I'm going to switch off and stop my share so that we can see the panelists. Before we continue, maybe it makes sense to ask Tim and Felix whether they would like to add something. Good point. Felix, Tim? There was a lot of work behind the scenes and a lot of work which hasn't been presented yet. That was a really good sample and a nice live demo from email and some of that. So, Oleg, I have not brought up the Q&A panel. So let me look at that. If we've got questions from the audience. Yes, we've got one. And yeah, please use the Q&A because we will answer any questions. And later, there will be a discussion where you can ask all the questions live if you want. Okay, so the first question. Do you have any recommended way of identifying unused plugins in environment with loads of projects? So unused plugins. That's an interesting challenge. To our panelists. I know that Cloudbees has a way of doing it. I'm not on the Cloudbees. So there is an open source plugin usage plugin which tracks plugin usages and configurations, but it doesn't track plugin usages in Jenkins pipeline. So if you just want to analyze configurations, which I involved, you could try using this plugin. But if you want to go beyond, yes, then Cloudbees plugin usage plugin. Well, and I confess, I've just used configuration as code and delete the plugin and experiment with a prototype. Now, that's that maybe that's a terrible way to say it, but many times I can look at the plugins description and say, oh, you know what? That is somebody's old thing that they brought in long ago. We should just get rid of it. Yeah, you can just have the disable button restart Jenkins and see what happens. See if anyone complains for ones that you think aren't in use and then just remove them later. Yeah, especially for plugins that are marked up for adoption or have other kinds of red flags. That's a good idea to check periodically. Yeah, I had just seen a recent issue come in where a number of plugins were flagged with security warnings. And if you've got a plugin installed that's flagged with security warning, this is a great excuse to consider removing that plugin. You've at minimum should upgrade it. And if I'm no upgrades available, now it's time at least to consider should I keep that plugin because it's got a known security vulnerability. We are always looking for contributors because for some plugins, especially in a long tail of plugins use just a few hundreds of installations. They know active maintainers and it takes time to deliver fixes there. So if you use this plugin, consider stepping up as a maintainer, and we'll be happy to help you to get started providing permissions and reviews we needed. We're looking for contributors. Thank you. Next question about future roadmap. Currently Jenkins uses a flat file system for its data and configuration. There are a few ways to attempt to keep the data such safe as a thin backup plugin or really raw if used to be the context of Kubernetes. But are there any plans for the future you're in far off to look using a database similar to SonarCube, how SonarCube operates? I can start answering this question because very good discussions about how we could switch to the database and moreover, there was some research about that. And if you go to Jenkins JEPs, you can find the JEP 2.13, which actually provides configuration storage API. I will put the link to the chat. So this JEP hasn't been fully implemented, but in principle, it's possible so that exporting color configurations to the database. Whether you should use that, it's a good question because my personal recommendation would be to just use configuration as code and infrastructure as code. So basically a combination of a jcask plugin and a pipeline as code. The job they said if you need it, and then you don't really need a database to store your configuration because your Jenkins becomes immutable. So it would be my recommendation. And I would differentiate between the configuration and the runtime data produced by build. So certainly for the configuration itself, the configuration as code is our best recommendation at the moment. As far as runtime build metadata, currently that is heavily file system-based, entirely file system-based in default Jenkins installation. We have some efforts in progress to let parts of that be replaced. So it is possible to replace artifacts in external storage. There's experimental support for keeping build logs in external storage. And maybe Tim can say what the status is of keeping test results in external storage. So all of these things combined at least reduce the pressure, reduce the amount, reduce the total volume of files that would be kept that you would want to back up. So if you're interested to find this information, you can just go to the Jenkins site. There is Cloud Native Sieg, which has been historically working on pluggable storage. And here you can find statuses for the main artifact types. So artifacts, credentials, system logs, test results. That's what available for previews, fingerprints. And she's talked to some on 20 projects. But for build logs, it's only partially implemented for pipelines, but you can use it. And task logs, configurations, code coverages and build storage is what we haven't implemented yet. But in principle, it's possible to implement. We are just looking for contributors. And if you're interested, please join the Cloud Native Sieg meetings because we can collaborate and get other entities implemented. Thanks. So we have an additional question. The question is specific to a particular plugin. I'm not as familiar with this as I might like to be. It is, is the UI for post-build action drop-down in jobs also resolved? So previously they were not able to scroll. I had to zoom out the browser just to see it. And I'm not sure I recognize this one. I don't know that I've seen it. Have any of our panelists or Oleg, have you seen any issues there that the UI improvements would have resolved? Post-build action. So it wasn't listed in the list of regressions. It means that it doesn't have the table layout. And presumably with the new version, it should get better visualization. I can probably test it synchronously while we answer other questions. Great. And then we can return back to that. Super. So then another comment. Thanks to everybody who's done the work to make the UI improvements possible. Now a question has been asked, are there any changes that would require code refactoring of user-defined declarative pipelines or scripted pipelines? So Jesse, this one might be one. Are you aware of anything in the serialization, the extreme code, or the authentication code that would require pipeline changes? No, there shouldn't be anything. Yeah, this should all be invisible from the perspective of someone using Jenkins. Definitely there would be changes for people writing plugins. But as long as you're writing regular pipelines using the sandbox, there should be no effect. Now, if you have, you know, groovy libraries or other unsandbox code that's doing strange things with Jenkins internals using direct Java calls, then you're in the same category as a plugin. And it's possible but unlikely that would be affected. Thank you. And Felix or Tim, are you aware of any places where the UI improvements would require any change to a user pipeline either scripted or declarative? Okay. No is a good answer. I like that. Great. Okay, then another question. I'm using CephsFS, so the distributed file system Ceph with the latest LTS version. Are there best practices to follow for using that file system? It's Jenkins on Kubernetes with JCask and using Ceph as the network storage. I confess I've not heard of many people using that particular distributed file system with Kubernetes. Are any of you as panelists, have you heard anything that could give any advice? Well, I had some support for Ceph recently, but the historically just works. So I cannot provide details about usage experience. I can talk for hours about GlastrFS, but what's the practical experience? I know that it works quite well. Thanks. Another question. And are there any plans to provide a build history per node for pipeline builds? Yeah, I can take that. No. And basically, because not that it would be especially difficult to implement, it would require some coordinated changes between Jenkins Core and One Plugin. It would definitely be feasible to implement and have it look like the freestyle version, but the performance would be even worse than the freestyle version, which is already sometimes a performance issue. And the reason basically is that if this question is about what I think it's about, if you go to the build history link under an agent, which is really only meaningful for sort of old style long live static agents, it's almost useless for a cloud system. But let's say you have some Mac mini in a closet where the Windows 2008 R2 server that you've kept online for a year and you want to see the list of all builds connected to it. The way that's implemented basically involves scanning every build of every project in the Jenkins controller in reverse chronological order going back to the beginning of time, loading the XML records for all of those, and then checking each one to see did it occur on this particular agent. And if so, show it in the list, which will work for a small system, but it can definitely cause IO thrashing and serious performance problems on big systems. And to implement it for pipeline, it would be worse because of the pipeline metadata is not just a single file because you can't because it's not necessarily just a single node. It's using every node block and there could be a dozen node blocks running in parallel. Each of those is stored with its own metadata. So we'd have to read all of those things. And basically, there's not a reverse index for all of this information. So this, you know, if we had going back to the pluggable storage discussion, if we had a proper relational database or something that held historical builds metadata going back through time, we could just say create an index by agent and retrieve from that index, but we don't have anything like that in Jenkins today. So this is something that would have to be left to some external dashboard, you know, Jenkins would stream information to and then it would render that information from its own database using an efficient technique. Thanks, Jesse. Thank you very much. Thank you. There was one question which I accidentally moved to answer about performance, where I can find performance reports about the Jenkins, for example, how many files I can handle in the Jenkins home and how many jobs I can run with a specific resource and integration. Does anyone want to take it? Okay, so that's as the documentation officer, that's an indelicate thing for me to painfully acknowledge, we don't have an awful lot of performance data on the Jenkins public site. We've got some rudimentary guidelines there, but that's about it. And in general, Jenkins at scale, there's been some interesting talks, a talk from Stephen Connelly some years ago on running live the largest Jenkins cluster at that time that had never been run. So there are certainly talks out there, but specific details on number of files or how much swap do you need or what are these constraints on IO throughput. The Jenkins project does not have that kind of information. Well, first of all, it truly depends on your pipelines, because Jenkins basically stores this execution context on the controller and handles the most operations on the controller. So resource requirements really depend on what tasks you execute with Jenkins. And if you want to do performance testing for your instance, there are some guidelines which you can follow or just use standard Java development tools and begin from there. But yeah, targets will be really dependent on the system you run. Thanks. So we've got another question that arrived for cloud images. I often see them become unavailable during the job and then the job just keeps running until it times out or is manually killed. Are there plans to add any pipeline scripting options to capture when an agent fails so that that portion of the pipeline can be relaunched on a new agent? Yeah, that is something that has been proposed. I mean, it's possible to do, but it's awkward, essentially, right now. So you can have, for example, you can have a retry block that just retries the whole chunk of work, including requesting an agent, waiting in the queue for it to become available, connecting to it, doing your build process and the cleanup at the end. But then, of course, if it's a real problem, a compilation error or something that's genuinely wrong, you would be wasting time retrying that when you know it's going to fail the second and third time the same way. It is sort of possible with some awkward scripting to inspect error messages from a failure to see if they look like something related to an agent outage. Right now, there's nothing provided out of the box that does this smoothly. Definitely something that would be interesting, especially if people use things like AWS spot instances where you know it could just be killed with very little notice, but just in general for any kind of agent, or you might have transient issues for lots of reasons that are hard to predict, and you would like to be able to retry a block. Unfortunately, nothing today. You can try using some plugins like local parts and build failure analyzer, which can catch particular events quite easily. But for these plugins, you can restart the job entirely for pipeline stages, et cetera. Yes, scripted pipeline with striketch blocks is the only possible response right now. Unfortunately. Thank you. Good. All right. So we've got another question about related to plugin downloads change to Artifactory. I'm not sure. I recognize that I'm not aware of any change in the plugin mirror infrastructure. As far as I know, we're still using our publicly maintained mirrors throughout the world mirrors in China, in Japan, in the US, three or four of them in Europe, three or four of them. So I'm not sure I do do others on the panel know anything that I need that maybe I've missed with regard to Artifactory plugin downloads. Maybe it's a reference to archive. Because yeah, when you download plugins using Jenkins update centers, you download plugins from mirrors. But if you go to archives, archives are being downloaded from Artifactory. Okay. Thank you. At least that's how I understand the question. Yeah, if you're using configuration as code or something, you would, I guess, normally be referring to some things stored in Artifactory. Configuration as code plugin. So if you talk about plugin installation manager, it downloads from update centers. It does good. Okay. If we talk about other custom tools, like let's say custom work package, install plugins to sage, all of them are also download from mirrors. So the only thing which downloads from Artifactory and all about is this thing. So if you go to the list, here you get the Artifactory link. Oh, actually, it's also updates Jenkins.io. So even that is not Artifactory. Yeah, so now there was a request to assure that we sanity check that the use of repose.jankins-ci.org was legitimately for the Jenkins project. And so we did have to change some things where we had mistakenly allowed some tools to be uploaded to the Artifactory repository. Those needed to be held elsewhere because they weren't strictly related to Jenkins. So we did that. But that's about all that I know about with regard to Artifactory changes. So yeah, please don't hesitate to reach out to the in the Gitter channel or stay until we switch the open discussion so that we can dive into this question. Thanks. Yeah, we have one last question. So for cloud images, I often see them become unavailable during jobs and then the job just keeps running until it times out and then they're killed. Yeah, we did that one. I think we got that one. So I've got some other questions that I wanted to ask our panel. So I'm going to shamelessly go to my questions. Is that okay? Maybe before we go that. So there was a question about post-belections. I can just show you how it looks like. So I have a test instance. It's basically the recent LCS release. And here you can see post-built actions like how they look like now. So the most of our post-built actions are compatible with the changes. They have been also updated. And here you can see that even message actions with a lot of configurations look quite well on the new interface. So yeah, there are still some plugins like let's say extended email plugin, which probably gets complicated even when we use these layouts. But overall, it looks quite good. So try it out. I don't have my next plugin installed. Excellent. Thank you. And just to remind everyone, there's some conversations in chat, but if you want something to be discussed, it needs to go into the Q&A window, not the chat window. Yeah. So the question, the most recent arrival was they're doing a lot of shared libraries right now for their Jenkins environments and reusing them. However, shared libraries, a majority of them, are not using pure groovy within the source folder, but rather steps within the vars folder. They have their own pipelines that run unit tests using JUnit pipeline testing framework, but because they don't have vars steps, they aren't able to pick up the tests covering any kind of percentage. So I'm not sure, is there a recommended way to handle how you develop pipeline shared libraries, I guess, is I think what the user is asking. And I'm not sure that we've got the right panel here, but let's go ahead. You don't have the right panel for sure. The description of right development approaches is what I would recommend. So, yes, write tests, yes, use vars if you want to have global steps, or use groovy classes if you want to delete them. Basically, both approaches are fine. There is no strict difference whether you use vars or whether you use classes except of encapsulation. If you want to see one of reference pipeline libraries, you can just go to the Jenkins project. We have a pipeline library here. So this is pipeline library, which actually builds Jenkins plugins and many other components. So here you can see the way out we use in the project directory. Jenkins files, we have Maven project, which basically triggers pipeline unit as well as some static analysis, etc. And here's our pipeline. So you can see here that we also use vars. So for example, build plugin, we involve in pretty much every Jenkins file, etc, the vars. But we also have some classes, not that many at the moment, but for example, document configuration management is stored as a class, which can be involved separately. But it's your choice how you use it. In our case, yes, we also store the majority of the code in vars because it's more handy. You know, the question was specifically about code coverage during tests. And I don't know. I will say that under the archetypes repository, there are a couple of samples of defining libraries. I can't remember whether using vars or source or both. That includes usage of the test system, but I don't believe that includes any system for code coverage. So what recommendations there might be, I don't know. I think you would have to go to the authors of that test library. Yeah, actually, it's talking about Jenkins CI slash archetypes, if you're doing screen sharing. Okay. This has a scripted pipeline and these both have these both have some sort of test infrastructure, but I don't think coverage. Yeah, we don't commonly measure coverage, though, in principle, pipeline unit should support that because pipeline unit doesn't really run Jenkins. It runs a groovy engine. So you can collect coverage from there. Yeah, I think the issue is with the vars directory, basically defining anonymous classes or, I mean, they're not actually anonymous and groovy. They are they are named classes in the default package, but perhaps the coverage tool doesn't work with that. Yeah, a couple of years ago, I had the similar issue with pipeline documentation, because I wanted to create a documentation generator for pipeline libraries. And somewhere in my GitHub, I have a converter code, which basically converts pipeline library, including class directory, the standard classes so that groovy tools can process them. If you're interested to reach out to me, I will try to find this repository. Thanks. The only higher level advice I would have is that if your code in the groovy library is complex enough that you feel the need for code coverage, then you should probably be working to simplify it and move most of that logic into external processes that don't require any complex setup to launch that's just run this Python script, something like that. And for the cases where you're genuinely interacting with Jenkins and genuinely do need some sort of logic, the use of a mock framework like the pipeline testing system is just going to be somewhat awkward because it's not going to give you all that realistic a view of how this is actually being used in the context of the system. So you might consider sort of higher level and to end integration tests at that point. There's not a single clear answer, I think. Yeah, for integration tests, we have two frameworks. One is Jenkins test harness, which you can use for testing pipelines, like we do for plugins. Another more advanced way is Jenkins file runner and frameworks around that. For example, Jenkins file runner test harness, which you could try, but this is a more complicated way and it doesn't fully cover all functionality. So my personal recommendation for common integration testing use cases, just consider Jenkins test harness, it works well. So basically it's the unit for framework with a lot of additional features like you can provision Jenkins, you can launch pipeline, you can evaluate restarts. Also, you can use test containers and other rules in order to provision environments. If you want to do it for the test, and this framework can be successfully used with pipeline libraries as well. So even if we develop it for testing plugins, it can be used for advanced pipeline library testing and Jenkins file testing as well. Yeah, many of our plugins basically just use it for testing pipelines anyway. So you're almost running out of time, but yeah, I will just show it quickly. So here, for example, you can see that we have Jenkins rule, which basically provisions Jenkins, and there we have a test somewhere in the bottom, which just emulates pipeline. I will look for that. You should have test, right? Yeah, here it is. So test pipeline compatibility, really simple example, which basically runs a pipeline on a Jenkins instance and verifies some results. Obviously, you can create more complicated examples with agents, with additional tools, environments, and you can also use configuration as code rules to automatically configure your entire system. The library plugin itself uses the same system to test pipelines using libraries to verify the different kinds of exotic edge conditions work as expected. Okay, and yeah, we have quite extensive documentation about this framework for plugin developers, which you can also use. Okay, so the next question, what will be the impact of the new version if you use Jenkins as code? Is it possible that we encounter errors with the plugins? And the answer is yes, it's possible, because when we talk about forms, yes, there are configuration forms, but actually there are many other forms. So for example, if I just start building these parameters, here's also a configuration for my class. And here, if something breaks in these plugins, the layout will be impacted. Another use case which you may experience is a pipeline snippet generator. So another test job. So this snippet generator, do you move for this snippet generator somewhere? If you just change the URL to top level to slash pipeline dash syntax, it will take us there without even going to, without the slash, yeah, there you go. And pipeline dash syntax. Okay. All right, we have to move to the site panel election. Oh, now that's interesting. Do you have pipeline installed? Oh, like I can certainly bring it up on mine. Well, whatever it is, just an example. So yeah, if you use snippet generators, not only pipeline, also job days, pipeline is YAML, then you may also experience issues because all these sections also create forms in order to provide your dialogue, which you would be configuring. Yeah, we'll find the link later. Just don't want to spend much time on that. Yeah, but I guess the, yeah, I'm not sure whether the question was about config is code of a job or config is code of the entire Jenkins system. But certainly if your entire system is being configured as code, then the same warning applies that you need to make sure you're using the latest latest versions of plugins available for the 277 line. Yeah, no, I was envisioning that maybe the question was focused on what if I've enabled extended read and intentionally not allowing people to do configuration changes at all in the system like Jenkins configuration. So Tim had done a bunch of great work on extended read. And that's now available in that case then. But that then is exactly what Oleg I think was answering to is that even with extended read, there are still presentation items in the UI shown to users that may be impacted by the configuration changes. And certainly the authentication changes need you to update your plugins. Also keep in mind that the configuration layout is just the first iteration and there will be more changes in layouts. For example, Tim has already proposed a pull request which changes run some risk page from tables to divs. So we will keep working on that to improve accessibility of the Jenkins web interface. And in the next releases, there will be more significant changes. Thank you. So Oleg you noted that we were approaching sort of our end. I've got questions but I'm okay with deferring my questions. I think we've got most of the question we've got the questions answered from the audience. Were there any comments that Tim, Jesse or Felix you wanted to share as we're as we're at this about one hour into the webinar Mark? No I'm good. So before we close, we will appreciate your feedback about the meetups so we can address feedback and future meetups, make them better and specifically interested to know what topics would you like to hear the next meetups because we want to organize more online meetups and any inputs would be appreciated. And if you want to present the Jenkins online meetup, please contact us because we are looking for speakers and we are happy to host any meetup related to Jenkins development, case studies and basically everything between those Jenkins. Thanks. All right. So I'm going to switch off the recording and then we're going to go live. Yeah. Thanks everyone.


All right. Thanks, everyone. Sorry for the problems. I just had to restart the computer, and that usually I was fixed as it, so it wouldn't connect. Thanks for coming to my talk. I feel a bit trapped back here, sorry. Talk is Drupal 8, the schema.org, how everything is connected. Essentially, what I want to talk about is how you can use, I guess, some of the latest things out there in search land to make your sites more relevant and more useful. I've done a lot of talks in the past on semantic web, which I tend to really enjoy, but they're very esoteric and somewhat more academic, and so I think semantic web in a lot of ways is something that we'll never quite get to, but where I was going with, whereas schema.org is something that actually is useful today and is something you can put in place today and see real value with. My name is David Peterson. I'm a senior solution architect with Acquia here in the Asia Pacific region. This is my Twitter handle, and I've got the Sunshine Coast office with Acquia. So me, myself, and I. So what I want to cover is what is schema.org and why you'd want to use it, some use cases, and then I will show some demos and things like that, so how you can actually use it in practice. So there's a lot of, Drupal 8, of course, has some really great tools for it. Schema.org is built in. There's also a tool called RDF Builder and RDF UI, which I'll show you as well. So I just want to run through a few example sites that are out there. So this is one of my favorite movies for comedy. So I mean, we look at this, and it's quite easy to see that it's a movie. It's got a 90% rating. It's called Raising Arizona, 85% audience, sort of average rating of 7.6. So again, I think most of us can look at that and just know that it's a movie. Same thing here. There's, sorry if it's cut off, but this is a pizza from an SPS site. And again, we can see that it's a recipe. It serves two, 20 minutes prep time, 35 minutes cooking time, and it's an easy skill to put together. Same thing here. There's just a commerce site. I tried to use Australian sites as much as possible. So you can see it's a cannon, how much it costs, the delivery, things like that, 12-month warranty description. So again, we as humans can look at all these things and instantly understand what they are. Of course, machines don't have that same flexibility. Google has gone a long way, and lots of search engines have gone a long way, to use their own artificial intelligence engines and all sorts of things to make sense out of this soup that's out there. But they're also driving forward the notion of semantic data or marked up data, which actually makes them, helps them do their job better. And so kind of coming back to the origins of what schema.org is. So back in 1992, when Tim Berners-Lee was first sort of formulating the very early parts of the web, basically I think this was the third web page that was ever, the fourth web page that was ever created when he was at CERN. He talked about actually having link types. So they actually dropped it. So we ended up having this href equals whatever. So if it's a document, if it's a person, if it's a video for 20-some-odd years, we basically hyperlink was just something to somewhere else. But back at the very beginning, they actually were thinking of using sort of a semantic type web of actually saying, is this a person or is this a document? He got shot down. They didn't pick that up, unfortunately. So it's taken about 23 years to get back to where we started at. And here's some interesting, these are diagrams that he also put together. So here's, again, a traditional link to here, to here, to here, to here, to here. It's all in terms of how a computer sees it, it's all just essentially a page with a hyperlink from here to here. So it's pretty flat, pretty boring, not very interesting at all. Here we can, angles are always good. And here you can see that actually these links were talking about many different things. And again, sorry for the, it's all a little bit anti-aliased and things like that. But here's a house, here's a person, there's an idea, there's a piece of clothing. So each one of these pages was actually a thing. And they wanted to describe those relationships. But again, it didn't quite work that way. So why did it take so long? What was the reasons for that? A lot of it was because the semantic web was driven by academia. And I think that's a good thing, because there's a lot of research that's gone into it. But it's also at the same time, the ability to sell, the ideas, the ability to implement the ideas were never really quite there. And for commercial enterprises and for businesses, there never really was a reason for including this kind of extra burden, if you will. But so here is, I guess, you can actually see what you can see today if you do a search for pizza. So this is kind of showing, well, why do you want to do this kind of stuff? So you actually get rich search results. You see, you do a search for cauliflower crust pizza. And you get images. You get ratings. And you get reviews and all sorts of things. So it's very compelling. And for sites that don't have this, which I'll show you later, there's a natural inclination for individuals to not click on things that aren't maybe as pretty. And also that maybe don't have as much information. I know when I'm looking at stuff, the ability to quickly see your different ratings, it gives you an idea, well, this might be more interesting or might taste better than other things. You see, there's 75 reviews, 94 reviews. So there's actually a lot of information in that little small area. And as we go through, I'll show you how we can do that. And here's some more ones. So these are Thai restaurants in Melbourne. So again, you can see some that don't have it. These ones just, this doesn't have it. But some of these other restaurants do. So they have ratings. Again, you can see TripAdvisor is doing a good job. But when we get to non, maybe the bigger players, they don't tend to have those sorts of things in there. And lastly, the other reason, and this is getting even further than schema.org, Google is building the knowledge graph. And that's really kind of taking it. That's been a multi-year project. There's billions and billions and billions of connections they have. And literally everything in the world has a Google ID behind the scenes. Some of those things that they share, and some of them they don't, they're actually going to be releasing a new API in April. They're deprecating the freebase back end, which is currently what helps them drive this. So you can kind of think of freebase as if you're familiar with Wikipedia, it's sort of a textual representation of the world, but it's not data. So freebase essentially took the textual representation of the world and turned it into a graph of data. And then Google bought them. And now that's why when you search for Melbourne, you get these rich search results on the side, which allow you to actually explore the graph all within Google. Google wants to keep you on their site. Facebook also has the social graph, and LinkedIn as well as the graph. And so if you click on, if I go back here, like if you click on National Gallery of Victoria, which I did, you're essentially traversing that graph all within Google and you don't even really, you don't even actually realize it. So as soon as you do that, you get this top bit as well, which actually allows you to see other points of interest within Melbourne as well. So you can kind of just keep on going, keep on going, and you can get, you get your traditional search results here, again with any ratings and things. But as well, you get these rich graph representations over here with reviews and all sorts of things. So really schema.org, I think one of the key drivers to that is really search engine optimization.  So I mean, really, as long as Google is doing it, that's kind of all that really matters. But I mean, we have Bing and Yahoo, which isn't really as relevant anymore. And Yandex is more of, again, more of a Russian search engine. But essentially, you have the big players going. And Google alone has, this is as of last year, but 15% of the crawled pages that Google indexes, which you can imagine would probably be hundreds of millions, at least for here, have rich schema.org terms in it. And they have over 5 million sites that they index actually have schema.org. So it's used a lot. And I was reading in the interview that I was reading through, previous to schema.org there was 10,000 sites along the web that used different markup. So you can see there was a massive increase from 10,000 for basically 20 years to the last three years to having 5 million different sites. So in terms of those rich search results at UDC, these are the different categories that you can actually, that currently have those search results. So we have things like product, recipe, review, event, software application, video, and article. So not everything yet. There's not visual artworks and things like that, but they're getting there. And here's a representation of all those ones that I just showed. So again, here's reviews. Here is recipes. Here's another review. Actually, there's a commerce item, sorry. There's an event. And you can actually see it even breaks down all the sub-events. There's a game, videos, and then there's news articles. So each one has a slightly different representation. But they're all, again, much richer and much more interesting than the static traditional blue headline with two or three lines below it. The other reason that it's quite interesting, as well as the knowledge graph, which I kind of touched on before when exploring Melbourne. So this allows you to traverse your content. And again, the reason that Google can do this is, first off, they have lots of money and lots of time. So they're investing all these resources, but they really want us to participate in this knowledge graph. And the way to do that is, again, well, before I get onto that, I did a search for Henry Matisse. And you can see y'all's artwork. And you can start exploring that. So it is pretty interesting. Recently, we're looking at dogs, for instance. And you can actually sort of choose one breed of dog. And you can actually choose other breeds that have a similar temperament. And you can see how many people are also liking those sorts of things. And I did a search for Australian War Memorial, which I'll touch on later. And as well, they have a rich markup for their site. The way that you can actually participate in this is by marking up your site with schema.org terms, which I'll demonstrate later. So previously, the connections were pretty minimalistic. You basically had one thing connected to one other thing with, essentially, one term. And there's about 400 different terms that you can attach to things. But now, Google is really pushing this to graph notion, because, again, they want to keep you on their site. So what they've done is they're allowing you to further explore this notion of a graph. So here, they're actually saying that if there's a Joe Montana, who is a famous athlete for the San Francisco 49ers, he has a role. And he's Joe Montana, who's his name. And then his start date is when he actually started playing his 1979. So you can see all of a sudden, we've gone from very simple connections to even more complex connections. And this starts expanding over. And I think Google has hundreds of billions of these connections in their knowledge graph. So getting to use cases. One of the key use cases is commerce, of course. So here's the URL for the schema.org slash product. And there's a very deep hierarchy to all different things. So everything has a root of thing. And then from that, we have product. And again, coming back to the Canon 700 camera, I did a search for that.  And so you can see that, actually, JBiFi, Kogan, Expert Reviews, Harvey Norman, and so on, some images. So again, this is all powered through Google. And these are the newer type things. But the interesting thing is you can actually see that Kogan actually gets rich results. They get ratings and things like that. You'll see that JBiFi actually doesn't. They just get the hierarchy at the top, the breadcrumb trail, but they don't actually get the reviews.  But for whatever reason, JBiFi didn't check their work. So here is JBiFi. You'll see that Google gives you this nice checker. So you get this big red flag that says Offer. It says Property Offer, blah, blah. You don't have to worry about that. But effectively, what they've done here is they've just doubled up on Offer and Offer. So Google essentially can them from rich search results. Even though they've done all the right things everywhere else, they've gotten 99 out of 100 score. But because they missed that one thing, they don't actually get to have a rich snippet. So it would be a pretty good idea if JBiFi would check that. Over here you can see as Kogan, they have Offer right here. See how it's actually showing a currency price and then the availability. And there's no warning flags at all. So if we go back to here, that's why we get Kogan with the rich search results. And JBiFi doesn't, even though JBiFi thinks they probably should be doing that. That was just, I just checked out about an hour ago as I was finishing up my slides. The next one is food. That's a very popular one with recipes and cooking and things like that. So again, there you can see the URL. Everything has a URL, so slash recipe. So now we've gone down a little bit. So it's thing, creative work, and oh, that's the wrong one. Sorry. It should just be food. Sorry about that. And here's an example of it. And again, we don't have to go into too much detail. But again, you can see slash recipe. You can see date published.  So effectively what they're doing is it's sort of almost like putting a class, an extra class of things. So item prop equals ingredients.  So it does bulk up things a little bit. But again, there's quite a good reason to do it. And there's lots of automated tools, which of course Drupal 8 is one of them. So I did a search for pizza on the SBS site. And that one looked actually really good. I'm really hungry right now. So again, the other interesting thing that I found was actually that's the title of that pizza recipe for SBS. But for what a reason, I wasn't finding it in the top search results, even if I put in gluten-free, which these ones actually don't even have. So the reason I think that is, is that SBS uses a domain name, as I scroll down. There's still no SBS recipe site or SBS recipe on there. And the very last result, the recipe shows up. But you see it shows up in the news. Again, there's a slight. They're being categorized as a news article, not as a recipe. So they're automatically dropping out of the recipes and showing up on the bottom. So even though they have amazing markup and they've got amazing, I checked their stuff. Everything clicks. But because they use sbs.com.au slash food, they don't actually have a different domain. Google has determined that sbs.com.au anything is news. And so therefore, no matter what they try to participate in, they're always going to be marked against that. So there's some interesting things that have to kind of keep in mind. Google is being a bit too smart now. It's just assuming that SBS is just news. So it's a bit of a double-edged sword, if you don't kind of watch it carefully. Because again, SBS is doing all the right things. But unfortunately, their recipe, even though actually searched for that exact title, did not show up on the very bottom. So they're actually getting marked against for you doing the right thing. So I think that might have to do more with how they rank their actual domain names. And maybe if they would add food.sbs.com.au, they might actually propel themselves back up. I don't know. I don't know if anybody said SBS is in the room. So here's their actual markup. And you can see they've got no tick marks. Oh, there is two errors. But they're minor ones. They weren't actually involved. But that one page that I showed you, it's recipe, name, cuisine, image, image, description. So they've got all this rich markup available. And they're doing the right thing. It's the sign in sbs.com.au is news. And so that's why I gave it a news headline. Even though it's actually giving them. And actually, you'll see that. They don't even get the recipe markup. They get the news markup one day ago. So why would a recipe have one day ago? So they're being marked up as news. So yeah, there's unfortunately their. Yahoo. Yeah, I didn't actually check on Yahoo and Bing it, actually, but it would be interesting to see what they've done with that. The other area of interest as well as the glam sector. So if anyone's not familiar with what glam stands for, galleries, libraries, archives, and museums. Of course, that's a large sector with a lot of information, a lot of really amazing connections. The schema.org tool set, if you are vocabulary, keeps expanding probably every two or three months. They introduce new terms and things like that. Just recently they added visual artwork, which is a huge big win for things like galleries, archives, and museums. And so one of the examples I wanted to show was the Australian War Memorial. They've been working with Drupal for a long time. And they've been doing, marking up their data in very semantic ways for a very long time. But again, they don't yet get those rich search results because Google hasn't released those lenses, if you will. But again, when you talk about the knowledge graph, the thing which actually is essentially even more important because it's all about discovery, the Australian War Memorial and other institutions like that are essentially building that knowledge graph for Google and essentially getting better discoverability. And the example I want to show with them is just slash person. So again, it's a thing and then person. So it's a very, again, a very small hierarchy. And here's an example of one person that I did a search for, which I'll show the data shortly. But here's a nurse from World War II. And within the memorial, they have a rich ecosystem of things and rich connections. And so this lady here, this is her dress, which is on display. There's a photograph that she appeared in. So all these things, this graph is actually being marked up within the memorial. And what the memorial is doing is they're actually exposing all these connections to Google, which we have never have known that all these things are related. So again, you can imagine that this will help power even more things in the future. So things like the glam sector, it is sort of a bit too early almost because Google isn't really doing the right thing by them. But at the same time with the knowledge graph, it's helping to power that.  That's kind of a sad thing.  And then you end up spitting out text and HTML and it might look nice, but you've lost all these beautiful connections. And what schema.org does, it allows you to actually populate those rich connections all the way from the database, all the way up to the website. And essentially what your site actually becomes an API because all this information can be scraped, which I'll show you as well soon and turned into JSON, turned into XML, turned into whatever, essentially automatically for you. So yeah, let's get to work. So kind of the key tools that I'll show is I actually have Drupal 8. So I'll show you about Drupal 8 and then also Google has some really awesome developer tools which I'll touch on as well. So of course, with Drupal 8, what could go wrong? Well, that's a bit of a leading question. So here I had my site set up, great, fine. I think it's beta seven is the latest one that's out there. So I had it in place and it was working fine. So I thought, great, I'll just grab the RDF module, which allows you to do these mappings and then put it in place. So of course you get the white screen of death and I was trying to figure out what happened. And of course there's some weird PHP fatal error, like something has changed. So what I had to do is I had to go back to beta four so with beta four, I'm happy again and I was able to get my content types going. So the demo I'm going to show is with beta four so it's a little bit out of date but the RDF modules that I want to show you, which are used for the schema.org mapping are only currently work with beta four but they don't work with any of the other ones as far as I know. Well, I tested them and they don't work. So with that, I'll switch to a demo. All right, so here's that same site. Pretty plain. You'll see there's a very basic thing here so we can just kind of ignore that. So again, we've got a very basic site. Everyone's favorite sort of garland theme. Looks pretty boring, but I'll click on structure and this is where it gets more interesting and I'll click on content types here. And now we get a new option which is add schema.org content type. So it's actually really cool. What you can do is of course you can continue to add content types as you would normally but you can actually build the entire content type of all the fields just by clicking and you get all the mappings done for you.  So any ideas of what I should search for? Any sort of content thing? Recipe. So if you start typing, there we go. Recipe. So if I, as I clicked on here, I'll maybe video, medical. So you can see there's all sorts of different nouns that are in this system. So I'll click on, I'll type out recipe again. And then just click next. So it's a little bit overwhelming but you get all of the fields from schema.org sent back to you automatically. And you can tick a little box if you want to include them and it gives you the name of the property and it does a pretty good job of matching it to the actual Drupal data type as well over here. So some of them are a little bit wrong. You can see associate media file, it's good. Headline, audience, things like that image. So it maps up pretty well. You can correct it. So if I scroll down, you can see that.  So these are all things related to a schema.org definition of a recipe. Cooking method, copyright holder. So what I'll do is I'll just quickly click on a few of these things. So I'll maybe click on about. I'll click on aggregate rating. Let's see cook time, that sounds good. Cooking method. Description there. And then maybe we'll find image, there we go, image. That should be good. And we'll just do a quick check to make sure. So image, that looks good. Description, we'll go actually text formatted long. Cooking method, text plane, cooking time, text plane. All right, so that looks good. So there's probably, I don't know, 100 fields here, of course, I don't think we'd want to include all of those. I'll click on save. So now what it's doing is it's going in, it's actually creating your content type with all those fields. And you'll see content type recipe has been created. And you get the different fields here, and then now we're back in Drupal land, essentially. So you can go ahead and the first thing I want to do is I'll just leave that, so I'm happy with that.  So here's my, again, my traditional Drupal thing. So I'll go with pizza, without cooking pizza. A rating will go five. Cook time, 10 minutes. Oven, and stuff about pizza. So anyways, just regular content type, which allows you, taps into the whole Drupal. And of course, you can choose an image, which I'll just leave for now. And I'll click save and publish. And there's my beautiful recipe. Of course, there's lots of styling, there's lots of extra things you want to do on here. This is very ugly and very basic, and no one would want to cook this ever. But you can see that, effectively, you've got all the things in place for that. So again, there's nothing magic about this. I mean, you could just create the content type and create your fields and you're done. But what it's done is behind the scenes is actually put in all the mappings for all these different things, for all the schema.org terms, which I was talking about, the things like SPS are doing. So if I click on these, and I go to inspect element. Okay, hopefully, so you probably can't see that. But we have things like schema recipe, and then everything that's aggregate rating, and things like that. So all those things are marked up in there. Yep, that's a good question. So what you can do is you can actually go to existing content types, and that's where you can go to, I can go to the article content type here and go to manage fields, and then I can go to the RDF mappings. So that's what allows you to now map, do the reverse of what I just showed you. So of course, you may have already your own content types created, which is most likely the case, because that's what you've already had. And you actually want to be able to then add those mappings to your content types. And so you would just do the opposite of what I did. I actually created the content type and everything automatically. You would just add the mappings to it. So all the same things are there, and all the same lookups are there, but you just have to do it manually to go for that. The module was created by a Google Summer of Code person that was working with SCORE. So Stefan Kulesk, who's based in Boston, he's been brilliant, I mean, he's been pushing a lot of stuff for years now. He had a Google Summer of Code student, she's from India actually, and she did this over the last few months. And so as far as I know, it's just schema.org, but yeah, I'd imagine it wouldn't be fairly easy to actually tap into your own vocabularies for universities, for public sector, for literally anything. Thanks, Stefan. All right, thank you. Yeah, is there any other questions on anything about here? So I've also got a site that's in the cloud. And the reason it has to be in the cloud is so you can of course check it. And this is a visual artwork. So this is one that I did earlier, and it's just a demo site that's in the cloud. The reason has to be web accessible so that you can actually use the Google, different Google tools to check the syntax. So if I just copy that URL, and if I go to the Google developers test tool, so, no, that's not good. Let me try reloading that again. I have screenshots of most everything, because okay, great. So Google's got some really great tools. Actually, let me just go back to the presentation and I'll just give you a quick rundown of those tools before I jump into that.  So it's just RDF UI with no space or no underscore. You can go there, you can download that. Just one module, it's got a sub module, so it's got the RDF builder, which I was showing you. So you just install that, and then effectively you get all the things that I was showing you. So it's kind of nice, it's just one module. And that was just stock Drupal. I didn't even turn on any modules at all. So out of the box, stock Drupal is using schema.org terms for the built-in content types and for things like that. But of course it would have no idea if you're actually creating a recipe or a commerce item or a car or whatever. And that's where the RDF UI builder come in as it allows you to define your content types. There is schema.org module for Drupal 7, which does very similar things. Yep, but there is, because of how Drupal 7 was implemented, it was implemented well before schema.org was out there, and it had sort of an RDFA implementation. So there's some issues with the markup that it produces and it's not as good as with Drupal 8, but there's workarounds for that. So yeah, Drupal 7 can participate. The only reason I didn't include that is just for time. But I was gonna actually, if I would have had a bit more time to show a Drupal 7 implementation with the schema.org module. Again, with Stefan is also a score, has put that together. So essentially anything semantic web or schema.org knowledge graph related in Drupal, it's score who's involved in it in some way or the other. And so here's some other tools that I'd like to show you. So the other ones that I want to talk to about are the structured data markup helper. So I'll show that one first actually. That one's really, really, really cool. And the other one is the testing tool, which is the one that I was just gonna show you. And then lastly, Webmaster Tools. So Google Webmaster Tools, which probably everyone's familiar with and has used before, now also has, if you go to Webmaster Tools, site appearance, structured data. You'll actually get sort of a 10,000 meter overview of actually all the structured data in your site and the different content types that it's found and maybe any errors, things like that. So it's a great way of letting you see sort of your whole pool of data and your pool of rich content for your entire site. So again, Google is really, really pushing this and they're really creating a lot of tools for it, which is great. So let me go to the structured data markup helper. It's a monthful. This one is really cool. Let me just find it. There we go. So hopefully we can see that. There we go. So this is nice, because what it does is it allows you to sort of step through the process of marking up existing content to get a better understanding of what's happening and how you can mark it up and doing it the right way. So it does, it lets you, and there's also things like email. So Google also, schema.org term, also you can put in emails. And if you use Google, you actually get those little buttons for actions. So you can RSVP things, whatever. That's all schema.org as well. So if you're booking a flight and you maybe wanna check in, if you see that little check in button on Google on Gmail, that's all through schema.org and you can check it here. But for instance, there's things, these are the major categories. So we have articles, local businesses, restaurants. So I'll choose restaurant, because that's an interesting one. And then any examples of Melbourne restaurant that I could try? Anyone? Anyone local? Any restaurant? Gringo Vibes? Vibes. That one? Great. All right, so there's Gringo Vibes. You can see it's a nice looking site. I wanted to be nice, I wanted to be nice. All right, I have to find my tab again, sorry. Where are we at? Was my tab, sorry. It's crazy. Okay. Sorry, I lost my tab. Did I override it? I just wanted to come over here. Okay. Okay, here we go, we're back. Restaurants, and I'll take Gringo Vibes. Again, I've never done this before, so I have an example one that I did use earlier. So I'll just paste that in and click on Start Tagging. So what Google is doing now is it's actually going out and grabbing that site. It's loading it in. This is a really cool tool. It's really cool. So here's the site, and here's on the side, structured data. So currently there is no structured data yet. So what you do is you actually start navigating, hopefully there's some text on here. See if it's any. Oh no. All right. So there's no text. So they've already lost the battle for Google. So we can do low, we can do image. There we go. We can get image. We can get a, it's not gonna like this. I'll try a phone number. I don't know why. It's gonna, oh yeah. It's not gonna like this one. So they didn't do too well. So let's try a site that actually has a little bit of text in there. S-A-R-T-I. Is that this one? Or this one? Sartita.com.au? This one. Great, there's some text here. I think I can work with that. All right, let's try this one again. Live demos never work. So I'll go back to enter page. Keep the restaurant. Start tagging. And this tool I think is quite new. I had actually never even heard of it before. I was just doing some research into different tools. So great. So hopefully, there's some text here. There's some text. Perfect. All right. Here we go. So I'll highlight that. And I'll say that that's the address, the street address. You'll see there it's showing up over there. I'll click on Melbourne, and I'll choose locality. I'll choose that, and I'll go to telephone number. I'll choose that, and I'll go to email. That's not the full email. Anyways, you get the example, you get the picture. Email. There we go. I'll fix that later. And then maybe we'll use that one for their image. So what it does, it lets even people who aren't semantic web heads and Google data individuals kind of participate in. It's not perfect. Let me see if they've got it. Yeah. Yeah, looks like it. I picked a random Thai restaurant, and it worked perfectly, of course, so I ask everyone. So I'm going to go to that random Thai restaurant that I picked, and I had no idea if it was going to work or not. And it worked really well. Where is it? Anyways, I probably don't have time for that anyways. But you can get the rough idea of how it's working. So you get telephone number, email address, and things like that. And you can click on create HTML. And what Google then does is it gives you back the exact HTML with what you actually need to add to mark up. So where are we at? There we go. So wait. It's a very terrible HTML for this site. You see that there's only a small section. So what Google has done now is it's actually added the exact schema.org markup that this company needs to add to their site. So at least to say that their address, their locality, their telephone number, their email address, and things like that. Of course, you would have to clean it up a little bit. They can further add that they relate what sort of food they offer and all sorts of things in their opening hours and closing hours. But it's pretty cool. And you can also then click on the JSON link data. And you can get a JSON representation of that exact same content. And then you can, of course, download that. Or you can enter that into your own site. So it's a really helpful tool. And the Thai restaurant that I randomly tried worked way better. And next time I won't ask any questions. I'll just use the one that works. And then the testing tool. I'll show that one really quick as well. I've got some of those preloaded. So I got all the URLs. But what I did is here's the JB Hi-Fi one. And here's, I just copied and pasted in their URL. And over here you can see that it's a product. So it's already knows that it's a schema.org product. And you can see that there's the one error. And the really cool thing is you can actually click on each one of these sections. And it goes to the HTML representation on the side. Sorry, you can't. This is gray. It's not, this projector is not very good. If I click on offer, it brings you right to the exact error of why they're not getting the rich snippets. It's because of this section right here. If they fixed that, they'd get rich snippets. So you can copy and paste any HTML in here. It was amazing. Literally, nine out of 10 sites that I pasted in here have rich data. Here's the memorial, for instance. Here's Frank Lee Beckett. I'll just put his name in, or the URL for him, that the memorial has. You click on fetch and validate. And that's not a very good one. Here we go. Again, stick to the script. Works better. Here we go. Captain Vivian Bullwinkle. She's the one that I was showing earlier. If I just, I've already, yeah, here we go. If I put her name, the URL for the representation of her on the web. Click to fetch and validate. You can see that person. You can see it. There's a few warnings and things like that. But there's actually an amazing amount of data that's in there. That's all about her. There's image, person. You see her birth date, death date, description. All of this is available as JSON. You just can take that URL, put it into a linting service. And there's also a nice, there's a lightweight one. So here's a structured data linter. You can use this as a service to get JSON out. So you can just put it in as you can get RDFA, JSON. So here's an example of what a rich snippet would look like if Google would finally put glam rich snippets in to put an image and information about her. And you can see here's a ton of structured data that it's pulled out of that. So the Australian Warmer Whirl has done a massive amount of work. All this is available. You can just grab that as JSON. You can start creating all sorts of things. And with linked open data, which is a whole other area, you can then follow that graph and walk around it and do all sorts of interesting things. So again, that dumb web page here actually has a lot of amazing real structural data that's in here. And these are all the same terms used around the world. So there's no ambiguity. That's the other beauty of it is that this death place, this death date, the birth date, is the same birth date as they would use in the UK or in India or anywhere else. So that's what also creates that global graph of information. And I think I'm running out of time. So I'll, sorry, I didn't leave any time for questions. There's Markup Helper testing tool. And there's a whole bunch more tools, which I didn't get to run through, Ruby command line things, and questions. Yeah, there is. I was watching, the question is what happens when there's a difference between what I'm saying about my site and what Google thinks they have of your site. So I was watching a video on that and the product owner for the Knowledge Graph said that they've got complex systems in place to fix that.  So they do check, but they are still wanting, you know, this rich data. So they were, again, they were very open about everything else, but for that one thing, they just basically kind of said, you know, we have complex systems in place to prevent gaming system. Any other questions? I realize we're at one minute over. If you're using Drupal 7, you download the schema.org module, put it in place and start adding these terms which has very similar look up and things like that. It works really well. Add it to your site and then use those checker tools. Use, and even if you don't want to do that, you can actually just go to that Google tool that I showed you because everyone here would create better sites than these rubbish ones with lots of text, which is good. And start adding the right markup to your site, testing it. So Google is great because it lets you check all your stuff and know absolutely if you're doing it the wrong way or the right way. Previously, there was no tools like this. There was no tool like that structured data one which took you to the exact line and said why you're doing it wrong. That's there now. You can fix that really quickly. And because you're working with a template system, you fix it once and you might have 10,000 pages that all start working better. And as you see, Google webmaster tools as well is also giving you that bird's eye view of your content so you can actually see the health of your site and how much content is being indexed. If, for instance, SPS is getting the recipes marked up as news, that's a problem. You can actually see that in the Google webmaster tools. You can see that your content is all being marked up as news, whether it's sports or whatever. So doing those little things allows your site to better participate. And if you use some of those existing 12 different ones, you'll get rich snippets usually within a few days and sometimes it might take a bit longer for other sites. And then they release new tiles over time based on popularity, essentially. So the more sites that are using this stuff, the more Google sees it, and the more likely they are to release a smart tile versus just dumb results. How so? Yeah, that was also one of the questions that I tried to follow. And they didn't really give a good answer to that one either, so I don't know how it works. I've done everything with English-based things, so I don't know. The question was, how does it handle multilingual? There's four different titles or something in different languages. I'd imagine they'd use some sort of disambiguation in terms of knowing that the canonical URL is this, and then all the different language settings would allow it to be searched better for other languages. So yeah, sorry, I don't know. I just thought English is the only thing I ever worked with. All right, thank you.


Hey guys, welcome to Archland. We're gonna be discussing kits of both Kabir and of Clarisse Are they really bait banners? So let's discuss their kit in detail on If you should decide that you should pull for their banners or not, okay? So starting off with Kabir, obviously the rating here for Pride with is late game. He's going to be AC And we'll know why so moving forward. He is a darkness tank Darkness which he has an ability with the three, you know primary elements you have Lightning fire and water you have advantages there But if you encounter light then he is going to have a problem Okay, so let's take a look at his kit. So he has a Leader unique passive So defense or physical defense increases up to 20% during battle increase damage Delta targets with debuff by 40 50 16 70 Okay, so he has a similar skill set or ability or you know a synergy or gimmick if you might say that with Peacock But Peacock is a warrior class who definitely Has more damage than this guy then Kabir So but similar mechanic They have increased damage when targets have debuff, but usually again that mechanic is best suited for warriors not for For tanks to take note of that So he has some skills here. So he has a a He can actually This is take take damage For allies within one tile when attacked. So he also does debuff And he also has exhaustion which is minus 20 physical attack and magic attack then a passive which is Um, this is weird. Okay. So this is an automatic damage When they attack you so more or less, it's more of a counter attack Passive then this one is counter attack damage. So he's built really for attacks not really for defense Unless if you want to get this one this this main skill you have to contend with that skill With that skill tree or row or Whatever you call it top or bottom. So next one is inflicting debuff. This one is for stun Receives less physical damage when attacked But again he is going to be more of His kit is going to be more on damage dealing not really on Being an escort being able to shield people and Again, he's kind of confused whether he's a tank or a warrior and this one is also attack Based on debuff. Okay. So for his old unique weapon, this one is gonna give him a plus one counter attack range, which is nice and Plus 15 physical taxuring battles who can't be removed So after a skill gain secret patrol for one sir. So that is it not really impressive just basic and Just my thoughts on Kabir He his kit. Okay kit wise he is a warrior stat wise he is going to be a tank So it's a bit conflicting on how to use him You can't really put him as a tank because his skills otherwise don't speak as If he's a tank But if you put him in a warrior in role He is also he can't also what he called this he can't also deal that much damage so again, he's gonna be fitting in the middle and In terms of that, he's going to be outclassed in the future That is why as you can see here. He is rated a C in late PvE So probably he's not even good in PvP. I don't think he's gonna excel in PvP So don't even bother bringing him in PvP PvE wise He's gonna he's gonna go down in terms of in terms of what they call this in terms of How he is ranked from A to C so again, I don't suggest him there are a lot of better tanks there I'm sure the banners for the other tanks will will go back around if you can just you know hold on a bit and Use your current tanks Probably SR tanks. They would be better than this guy So I would suggest holding off summoning for Kabir Again in terms of pros and cons Increased attack is increased damage in if targets are debuffed again. That's a warrior skill can debuff It's done enemy. That's good. But again, he is a tank. His stats are for tanks. Okay So only the darkest element actually makes him decent and Again, he's going to be dipping if you're gonna be using him dipping Towards the endgame towards probably non-existent. So you could probably use him now, but down the line I don't think you'll be using him. So those are my thoughts with Kabir If you can just hold on guys There will be good tanks or probably there'll be a rerun of tanks or existing banner existing tanks that will rerun their banners So more or less, you know, just be patient and you might you know You might be able to get lucky with the other tanks, but again do not Summon for Kabir. Please do not. Let's go to Clarisse here and see what Clarisse can do. So Clarisse was a free character Okay, so imagine me telling you that right now and you just play the game Clarisse is a is a free character When you when the game started I nearly wasn't able to get Clarisse But fortunately I did I was actually able to summon a second copy of Clarisse. It's weird But again Clarisse is a decent for me. She is a decent Assassin she's rated pve early PV late S She can also be good in PVP provided that her you you limit her targets to soft targets When I say soft targets It's gonna be priests and mages Because she can ignore escort that is actually her strong suit so if you want to eliminate a couple of a couple of What you call this a couple of soft targets mages and priests early on then in you know You can even have a swap kill one. It's okay that please is being killed But if you kill a an important mage or an important mage or priest then It's going to be a win-win for you, especially if that support is very good Okay, the drawback for Clarisse is that she is fire Water right now is very very good in PVP So Might as well, you know try to be more cautious when using her. Let's go over skills. So she gets More damage with active attacks meaning with your basic attack after killing enemy gain Movement after the battle two to three tiles and gain dodge buff for two thirds So the important that you select the softest enemies so that she can move And Dodge avoid incoming attacks. Okay. So again, she has fire Um increase her critical rate so that you know most of her skills here Give her an increased critical rate which Makes her lethal in killing soft targets as well Do not let her go one-on-one with hard targets because I'm sure she she doesn't have she won't be able to kill them So be be be selective really and she'll be effective for you Especially if you could kill then go out of harm's way then that would be very good So as you can see she she has a lot in her kit critical crit rate increase crit rate increase This one is ignore escort So this is going to be very good and also she has ignite she gives it night Which is also useful ignite as well um increase physical attack defense by tem which I think you won't need especially if you She has a very good dodge and she also gives exhaustion as well and ignores escort so two skills for ignore escort And what can I say um if you use her if you use her? Well, she cannot be played in in auto definitely off to manually play her for pvp and for ppp I think she is also rank s for pve for pvp because um again for pvp you just need to kill a few select um what do you call this few select uh A crucial target especially if they're they're squishy them They're they're gonna be you know, they're going to be falling Uh once Clarisse, you know runs in their way so moving on to a unique weapon So physical attack plus two critical rate also increased by two percent rated blade for every two turns every time you move through 14 tiles so rigid blade is plus two physical attack Plus two crit attack when using an active attack attack the enemy with ignite When it when afflict the enemy with ignite the effect is removed after attacking Okay, so not too special weapon, but nice to have and again as you can see here I probably I I actually just the ramble, you know, um How she's good at picking her targets soft, you know soft targets is is the best for her She has good dodge, but she cannot dodge all day. So make sure that she is not cornered Because again She will really die. She can't dodge hundred percent. I'm sure but again, she could probably dodge one or two But of the third I think should be gone. So great again killing lone targets squishy lone targets To burst the map with very good mobility and can really have very good dodge. So those are my You know my thoughts on both kabeer and Clarisse um For beginners who don't have Clarisse. I'm sorry. Um, you missed her in You know the freebie when we started But again, if I give you my honest opinion if you're good with Clarisse Then going Clarisse Um, but the best assassin in the game with similar play style would be semi So if you're good with Clarisse, um in getting her and you like her play style Then get her but if you're willing to wait, okay If you're willing to wait for another rerun for semi again, uh semi I got I got in her banner and I got her off banner That's weird Both of them. I got off banner. But anyway, um If you're you're really patient and you really want to wait then say about for semi Or probably you could get a semi uh off banner pull probably So again, semi is the best. She would be second For assassins with the same play style Um, I'll be I'll I'll be comparing assassins in the future because we have michael with a different play style But again Clarisse with the same almost the same play style as semi Uh will be second. She won't be first. So I'm sorry Again Clarisse if you want to pull for her if you need her in your roster If you want to build her if you just enter the game Then go for her but but but but hold on I have a second video in a while Which will give you guys a teaser on who's coming up So before you decide on these two as well, check out the teaser Check out the next video while you're at it. So, okay So thank you very much guys for staying this far. Take care. Stay safe. This is the warden and I'm out of here