 Good morning. Good afternoon. Good evening. Wherever you're hailing from, welcome to another edition of the developer experience office hours here on OpenShift TV. I am Chris Short, executive producer of OpenShift TV. And I'm joined today by a regular face, Ryan Jarvenin, but also two new faces, Mark Nury and Rohan Kumar. Mark, do you want to go ahead and introduce yourself to the audience? Hello, I'm Mark. I work as a software engineer for Red Hat and I'm currently maintaining the Fabricate Covenants client and the Eclipse JQ project which we will be showing today. Awesome. Rohan, go next please. Hi guys, I'm Rohan and I'm also working together with Mark on Eclipse JQ and Fabricate Covenants client and I'm really excited to be here. Awesome. We're happy to have you here. So, you know, this is new to me. I'll be honest with y'all. So, Ryan, would you like to introduce yourself first? Sorry, I totally forgot. No problem. Yeah, yeah. And I'm a regular on the channel. So hopefully, say hello in chat. You've seen me before. I'm Ryan Jay from the developer advocate team, OpenShift developer advocate team. I have had the chance to use Fabricate a couple times in the past. So I'm really excited to see how things have evolved with this JQ project. Yeah, as am I. Are folks in chat familiar with Fabricate? Hopefully, we get some responses in there from the past, especially if you're using doing kind of automation around Java projects, Fabricate hopefully is familiar for some of you folks and then pull up the chat and jump in there with you folks. If you have any questions along the way, feel free to throw them at us and we'll do our best to answer as usual. Code Walla Walla says Fabricate is great. JP did says he has no experience with Fabricate. So this is a good audience already. Cool. Mark, you want to kind of show us? Okay, I just want to start with a little note. Fabricate was a huge ecosystem, which consisted of several projects. So this is also important to highlight JQ. For those who were familiar with Fabricate, JQ is the successor for the Fabricate Maven plugin, just this part. Okay, so most of the Fabricate ecosystem is deprecated. The other project that is still alive is the Kubernetes client, which we also, Rohan and I maintain. And yeah, these are, well, there are a few other projects that are still alive, but these are the two that we handle. So what we are going to show today is more the part or the new version of what the Fabricate Maven plugin used to be. So in case you were a Java developer, you might be familiar with this, with this plugin, which is something that you would add to your project in order to make it compatible with the with the with the cloud, right? To be able to deploy your application to a Kubernetes cluster. So yeah, I'm, I'm familiar with Fabricate, but JQ is all new to me. So I'm super excited about the show because I get to learn something. So what is JQ? What is its goal? Yeah, okay, so for those of you who don't know what Fabricate Maven plugin was, or in case you've forgotten, JQ is this successor for this. And what it's basically is a set of tools and plugins that will allow you to deploy your Java applications into Kubernetes or OpenShift. Okay, so it consists of three components. The main decor logic is implemented in something that we call KIT, and this exposes a Java API that you can use to generate your container images or your cluster confirmation manifest. So on top of this core KIT, what we have developed are two Maven plugins. The first one, the Kubernetes Maven plugin is the one that you will be using if you are using a vanilla Kubernetes cluster or you are targeting on a Kubernetes cluster. And you can use this to generate container images, and then to generate the cluster configurations, the original files, and to apply them to the cluster. It will also offer other things like generating home charts and so on. But just to, for the overview, it's not that necessary. Then on top of this Kubernetes Maven plugin, we have the OpenShift Maven plugin, which is more specific if you are targeting an OpenShift cluster. So in this case, the default build strategy will be S2I binary builds. So this is what the builds will be performing in the cluster. And then it will generate more OpenShift specific configurations. So for example, it will use deployment configs, or it will generate routes, and so on. So it will produce general configurations, which are more specific for OpenShift. Okay, so basically, just in a nutshell, it's just a Maven plugin that you will be able to add to your project, and it will automatically allow your application to move into the cloud. So the way this works, if you are familiar with other tools, such as dev files or scaffolding or so on, in those, you usually configure the way in which you want your images to be built, and how you want them to be deployed. You provide something, right? In the case of JQ or the Kubernetes Maven plugin or the OpenShift Maven plugin, it's a little bit different. So JQ is smarter in a way. And in this case, the first step that will do the project whenever you invoke any of our goals is analyze your project. It will check the dependencies, the properties, the configurations, and so on. And it will do this to detect which frameworks or which technologies your Java project is based on. According to these inferred configurations or input variables, it will generate some opinionated defaults, and it will generate your images and your configurations according to these defaults that we consider are the best for that application, considering the framework and so on. So for very simple applications, just by adding your, the plugin to your Maven POM XML, it would be enough to deploy that application into the cloud. So of course, there are applications which have higher complexity and we all want to configure more specific stuff and so on. And then we have options to configure the way the JQ behaves. So you can provide some excellent configuration in order to override the defaults that we inferred for you, or you can provide even small fragments of your cluster configuration. You can provide partial files that JQ will read and it will merge with the ones it generates for you. So yeah, I think it's a very powerful tool and in case you're working with Java Project, it's something that it's definitely worth a try. Awesome. So in case you're watching the stream chat, there is a developer experience feedback survey. Let us know what you think about this episode. Let us know what you want to see in the future as well. So feel free to hit that while we're going on here. So Mark, go ahead, Ryan, sorry. Shout out to Natali Vinto, Bluzeman84 in chat. He's not here quite yet today. He might drop in a little bit later, depending what we'll see. But thanks again to Natali Vinto for helping invite our guests today and bring this topic to the show. So thanks again. Let us know via that survey link if you have topics you'd like to see. Nice. All right. So want to show this thing off here, Mark? Yeah. Okay, so let me start by sharing the screen. So not sure how this is going to work. Just let me know. You can do it. I believe. Yeah, no problem. Take your time. Yeah, it looks like folks from the audience seem to be vaguely the folks that are chatting at least sound like they're somewhat familiar with Fabric8 and definitely with Java. Okay, so I'm not sure if my screen is already. Yeah, I think. Yeah, you're good. Yeah, looks good. So we are usually when we are demoing or in other conferences, talks, and so on, we are usually showing the inner loop. So how a developer interacts with OpenShift or Kubernetes by using jcube. And today we wanted to show something different, because in most cases, jcube is something that you want to use in the outer loop too. So to define your pipelines and maybe your continuous delivery strategies. And the plan for today is to bootstrap a Quarkus application, add jcube, push an image into Quay, into Quay registry, and then deploy this image into into the developer sandbox cluster that Red Hat provides for developers. All of this using a GitHub actions workflow. So, yeah, I don't know if it's clear. So far. Okay. So, okay. Question in chat. What is the integration with CI CD tools such as Jenkins or Tecton? Like, okay, so you will see today with GitHub actions with with a GitHub workflow, it will be more or less the same with Jenkins. Basically, you I mean, when we finish the pipeline, you will see that it's something really, really straightforward and easily portable to any other platform like CircleCI, Tecton, Jenkins, whatever. Okay, so I'm going to start with this repository, which is now empty. Okay. And the only things that I have are for secrets that will be used in the pipeline in order to be able to both deploy into Quay. These are some credentials for Quay. And this is the token for the for the sandbox. Okay. Got it. So, first step. So you want to bootstrap a Quarkus application easiest way, you go into code.quarkus.io and you add whatever dependencies you want. In this case, I'm going to add rest easy. And you click on download the zip. There you go. You have a bootstrap application for you. So this is my idea. I'm going to unzip this here. Second because And by the way, audience, if you cannot read something on screen, please let us know. We can always tweak things. Yeah. Okay. Okay, so now it's taking a little while but anyway. Well, you've got your camera and everything else on zip something compression, you know, that kind of thing. Okay, so now we recognize the project. I don't know why it's not showing up here. Yeah, I always struggle to do demos and type at the same time. And especially try following along with chat at the same time as well. Another level of Yeah. Exactly. Okay, anyway, the project structure has has updated. Okay, so well, when you when you would start the project, the first thing that you might notice is that it creates this Docker directory with some Docker files, lots of stuff here, both for native and for JVM mode. So the good thing with JQ is that we can go ahead and remove this. Not needed. Okay, let me check my notes. I don't want to miss anything. Okay. So also, the bootstrap project contains a test which tests the endpoint. I'm going to remove this because I'm going to change the endpoint a little bit. So in order to speed things up, I'm going to remove the tests. But please never, never remove your tests. In fact, you should be adding tests for everything that you implement. Okay. So, okay, so this is the endpoint that's provided for you when you watch the project and chase. Hello, rest easy. Let's modify this to open shift. Okay. And now, basically, we lose you. Might have lost him. I don't know. Yeah, he said he was having power issues. The screen share is still going now. Yeah, but it's not moving. Yeah. Wow. Rahan, are you the backup? Are you second fiddle here? Or congratulations, you made it to the front row. Yeah. Okay. So the plan was that if in case his power goes down, I'll showcase the inner loop perspective. Okay. So I was kind of joking that you'd have to jump on right now, to be honest. But if you have something ready to go, that's super cool. Yeah, I don't know if you lost mark for good or not. So yeah, hopefully rejoin. Yeah, I think I'll go with the inner loop for now. And I hope that he comes back while we are demoing that. Sounds good. Okay. So I'll go with starting to share my screen first. Yeah, you should be able to call out. And if not, let me enter a screen. All right. Can you see my screen? I can see me. Okay. All right. Okay. So I already have that caucus project bootstrap that was bootstrapping. So I'll just try to open it up with my IntelliJ. And it's going to take some time to load up. Okay. Is this a different IDE than we had that? No, I think it's the same one. Yeah, both our IntelliJ or demo iterations. So I think it's the same. Maybe he has dark mode on or something. Yeah. Yeah, he has dark mode on. I usually keep the mode to light mode for presentations. Yeah, since it's a bit easier to see. Anyway, so this is a standard caucus application. So as you can see, Mark would strap the project and it would strap the standard caucus project with all the standard dependencies. So very basic. And it has this simple endpoint of hello, and where we are simply running OpenShift, hello OpenShift.tv. So let's just try to run it from our locally caucus.mvn. So in order to run it, I'll just package it first and just compile it so that the job builds up and everything is fine. Is this like a test pass to make sure that it'll Yeah, I have built it earlier as well, but it's just a test pass. So it should be finished now. OK, so in order to run, I would run it just like any other caucus application. So so I'll just run it in caucus.mvn. And I think we should be able to see it on, access it through a browser. Oh, it's accessible now. Oh, it looks like Mark's back. OK. Yeah. Yeah. Yes, let's just keep rolling with Rohan's deal and. OK, sure. All right, so I just launched having been caucused there and I was able to see the application running locally and our end point should also be doing just fine. Hello OpenShift.tv. So there you go. So we have the application running locally and as a job developer, this is the thing that we are all familiar with. We are all familiar with reaching our code and deploying it locally onto our local machines. But now we want to deploy this same application to Kubernetes. And here for Kubernetes, usually our developers have, when they are testing the applications on top of Kubernetes, they usually have some local Kubernetes clusters running where they can play with the application. And right now I'm using Minicube for that and my Minicube seems to be running. So first, I'll start with containerizing this Java application into a into a container image and pushing it to some container registry. So if I would have been not using JQ, I would have to write a Dockerfile first and then run the Docker commands like Docker build, Docker push to do that. But when I'm using JQ, I only need to add this plugin. So I have already added it just to save time. So in order to use JQ, you just have to install a simple plugin in your Pongot XML. So just like any other Mewen plugin, you are just adding another Mewen plugin to your project, which deals with the Kubernetes operations. So once this plugin is added, we can go ahead and start using it. So I'll first start with containerizing the application into a Docker image. So first for that, it's just easiest running this code and we get this build. And since the plugin is in profile, Kubernetes Mewen profile, so I'll just specify the profile here and it's going to start building the container image for our application. Cool. And this is similar to the, like Mark deleted a bunch of Docker stuff out of his repo. Yeah, yeah, it's because of the equivalent. JQ generates them, so JQ generates them automatically. And you see that JQ took this image as the base image for our application. And I'll show them. So JQ, I'll talk your Docker. All right, so JQ generated a default open-unit Docker file for you and it submitted it to the DockerDemon that was running. And it used that to build your Docker image. So I'll try to run this image locally from here. Docker run, okay, it seems to be running just fine. And just like running it locally. So now we want to push this application. So generally, this is the standard workflow when you're working with Kubernetes, you have to containerize your application, you have to push it to some registry, external or internal public registry. So I'll start with pushing it to my Quay. And for that, I'll... So right earlier, we saw JQ built the image. Let me check the images. So JQ built the image with some default name because we didn't provide any kind of configuration of what kind of name we want to have. So we can easily change, we'll first try to change it and we would need to change this to align it with standard Docker image names like registry, username, and then name of the repo, tag, et cetera. So in order to do that, I'll just do MNK just built and I'll provide that parameter to JQ that JQ use this as the name of the image. So the history will be Quay.io. I'm just going to append it to the name and my username. And the quote Quarkus, what was the name? Quote with Quarkus, okay. And the MNK just built Quarkus and latest. So this would configure JQ to generate the image but with this name which would allow us to push the image. Oh, sorry, I forgot to specify the profile. And it's in the Kubernetes profile. So one thing that's really nice with JQ is that you can use it like any other main plugin and we are used to use different kind of profiles when we are building projects. So you can have, you are building your application in standard mode, you just build it as a jar when you can have a Kubernetes profile or Docker profile too. So to have your image, have your application packaged as a jar or as a Docker image. So, okay, so the build finished and seems like JQ created the image for us with the standard with the name we provided. So I'll just try to push it. I would need to specify the property again. Okay, so then I have, so JQ allows you to configure the registry credentials either through Docker login or through your Maven settings.xml or through the plugin.xml configuration. So you can configure the... So I'm pushing to some registry and we need to provide credentials for that. So I have them in my M2.xml, settings.xml. Just like any Maven repository, you provide credentials for your Docker registry, container registry here, and it's gonna work fine. So it's pushing now. Yeah, the good thing from with JQ is that it reads the credentials. So let's check whether the image is there or not. So I'll go to that way and code with Quarkus is there. Tags, and yeah, looks like it was pushed a few seconds ago. So we looked at how we containerized the application to a Docker image and pushed it to some registry without even having to take a look at Docker or Docker files anything. Just plain old Java way of doing things. So now we will try to generate the Kubernetes manifest. If you are not using JQ, you would need to use write the manuals, but JQ has a goal for that, which is to communicate this resource. And it's going to generate opinionated manifest for you. And I would need to specify. So, okay, I think I can just add it here in my POM.xml, the property for the image name. JQ to generate. While you're working on this next step, you might have to pause it a little quick for questions. This can easily configure through properties, but for now I'm just hard coding it here. I'm not sure. Okay, so I'll just try to include this resource and the Kubernetes profile, and it should generate the resources for us. So it's okay. So as you can see, it generated a service, and let me show you the project folder. So as you can see, it generated the target classes. It generated the Kubernetes manifest. It generated an opinionated deployment for us with some additional things, additional labels, which can easily be configured. And it generated a default service for us. So all this without even knowing how to write YAML or anything, so which is really a good point when you're getting started with Kubernetes. So, awesome. And the image name also seems to be correct. So we built the image. We pushed it to some registry. We generated manifests as well. So we just have to apply it to Kubernetes cluster. So we can go ahead and do that as well. So just like Qubectl, due to Qubectl apply, we have this code called ambient keta supply, which would just pick these manifests and apply it onto the Kubernetes cluster. So I think it's hilarious that you and I have the same problem spelling Kubernetes at times. Always the R and the anti-reverse. Okay, so it looks like it deployed the application and Pod is running as well. So I'll just shoot it again. Okay, I think it's from the previous one when I was testing the demo. And I'll check the services. And it's a cluster IP service. So which means the application is accessible from within the cluster. We'll change it later. And okay, an application seems to be working fine. And I'll just exit it from here and I'll generate the resources again. So by default, JQ generates the service with a type cluster IP, which means it's only accessible from within the cluster. But let's change it for the demo purpose. I'm in Kubernetes resource, keep the supply, and I'll just provide a property in JQ.invichir, JQ server type, and I'll just specify the profile here. And it should update this service type to our node port. So. Well, this should let us curl that particular service from outside the cluster. All right, so it looks like it's a node port now, so we can access it from outside cluster as well. Just check what's the node port. So our node port service can be accessed as at a static port on the node's IP. So we should be able to access it like this. And yeah, now our application is running inside Kubernetes and I'll just try to check the hello, and it also seems to work just fine. So this pretty much sums this demo for, I mean, the first part of the demo, I'm not sure where the mark wants to take over from here or not. Yeah, Mark's back. He seems stable for now. Welcome back. Yeah, sorry for before. I'm having trouble with electricity this afternoon. It's really bad timing, sorry for that. You should have gone into the office. You're so funny. Yeah. Okay, anyway, I'm not sure if my connection is fine or my videos are fine. It's fine. Thank you. Oh yeah, I'm going to share again my screen. I think we were just around the spot. You had just deleted the Docker's bits and they moved maybe a little bit past that. Yeah, I think it's good that Rohan also showed his part because we actually got to see what I'm going to describe in the pipeline. So any questions for Rohan before we jump into this next bit? Yeah, good point, Ryan, right? Like there was golf claps, people were hyped in chat, but any questions? Was that not clear? It seemed pretty clear to me. One of the first steps that you did, Rohan, was a maven build locally. That build is actually going to happen in the cluster normally, right, when you're running that? So whenever you are packaging your application, you would be packaging it as a container image. So you would put the jar inside that container image. So I don't think it would be... Oh, so you would be doing a local build. It performs a local build, but if you are using the OpenShift Maven plugin and it uses the S2I build strategy, the build will happen in the cluster. So it depends a little bit. Configurable. Okay, all right. I just wanted to make sure I understood the workflow, how things were going. And especially when you're doing local, you want to do those builds locally and get that local test feedback before you make your commits or promote your changes. So yeah, nice job on the local loop. Definitely. Okay, so yeah, from my side, so I'm not sure why part of this... The wrapper, I deleted the wrapper. Anyway, I would use the Maven normal. So basically when Java 11, okay, sorry, my flow stopped before. So now it's hard. Okay, but basically the application we bootstrapped should build normally. We remove the tests. Yeah, so now we can configure the POM. There's one small change in the new... In the new Quarkus version. And by default, it's now using fastjar packaging. But JQP still doesn't recognize this. So we are going to configure the application to use the Uberjar instead. So basically when we package the application, we should see here the runner jar. Yeah, so we generate this runner. Okay, and next thing I'm going to do is I'm going to create a profile specifically for the CI environment. So for the build, I'm going to add the OpenShift Maven plugin. Okay, I have a few properties that I'm going to describe now. So as you saw before, Rohan configured the name of the image. This is important because we are going to publish this into the Quarkus registry. So it requires that these matches with my registry information. Also, since I'm going to use the OpenShift Maven plugin and I want the build to be produced locally because I want to push it. We still don't support pushing from the OpenShift Maven plugin. So I'm going to use the GIP strategy, which does support it. So what J-Cube will actually use GIP in order to build the container image. And then, since we are going to deploy to the Dev Sandbox, usually J-Cube generates a deployment config, but the Sandbox is based on OpenShift 4.5 or 6 or 7, I don't know. We still don't support. Sorry, my bad. Okay, so anyway, what we want is to generate a deployment. Also, because in order to pull the image from GIP, it will work better. So basically, this setting what generates is a deployment instead of the default deployment config. Since we are working with a snapshot and we are not providing versioning, so the image is always in the latest. What we are telling J-Cube to do here is that whenever we apply the resources, that it should recreate them. So it will tear down whatever it created before and then it will create new resources for that. And again, for the deployment pull policy, we are going to use always. Again, because we are using this latest stack and we are going to overwrite it. This could be like maybe the continuous delivery pipeline for a Dev environment. So we are using this latest stack and we want it to be refreshed. So even if the image exists in the cluster registry, we want it to be pulled again. So this is the other setting that we are going to add. Okay, so this is my query register, which is empty. And now I'm going to start by creating the GitHub pipeline. So, okay, so this usually goes, this goes in the GitHub workflows directory. And I'm going to create pipeline. Okay, so I have some settings already. Okay, so the name of the pipeline, demo pipeline. And we want this workflow to trigger whenever we push to the main branch. The first steps would be, I'm going to remove this because I didn't add the wrapper. Okay, but what we want is, this is what probably all of you are familiar with. So basically what you want is to build the project and check that everything works and so on. So some of the files that were added with the Quarkus bootstrap, I deleted them by accident. And now... Oh, boy. Anyway, I'm going to just use this feature from... Okay, anyway, let's see. Is there the advantages of using an IDE? I'd never be able to undelete things with my command with my Vim editor. I know, right? Okay, so lots of stuff got added here by accident. Yeah, anyway, this is the important thing. And commit files. So this was the empty repo. It should contain some files now. And a new GitHub Action workflow should have been started. Okay, so this is usual stuff, right? Check out the repository, set up Java 11, and start the build process for Quarkus. Hopefully this will complete once it allows the dependency. The project is not that complex, so it should take like 30 seconds. But basically this is what we all know. Okay, let's wait for it to complete. So build success, and yeah, it completed successfully. So the next step that I want to add is the push-to-quay. So what Rohan did manually, we can add this to the pipeline. So again... Where was that build running? That last one he showed? Yeah. In the GitHub virtual machine. So the workflow working on a virtual machine. So you define... Well, yeah, you define here the base image where this job is going to run. So this is running in Anubuntu virtual machine on GitHub. Okay, so my laptop is not... Right now it's free. As we were saying before, for the credentials, when pushing, JQP is really smart and it will try to infer them from your laptop. So if you have settings in your M2 directory or if you have your... You logged in through Docker or whatever, it will take them from your laptop. But since we are running this in a GitHub action, we need to provide these credentials. One of the ways that we can provide them are by using these variables, okay, these properties, these minimum properties. And when I was showing you the repository, I also showed you that I had these two secrets defined. So these basically are defined here. I will show you again, but very quickly. So quit username, quit password. And this match with my robot account. So I have a robot account, which has credentials for this specific repository. And these credentials are the ones that I stored in my GitHub repository. Okay, so just by adding this, we should be able to push to Quay. We should see another action being triggered now. Same steps as before. The first thing, it will build a project in the virtual machine that's put stuff here. And then you can see the new step that's already here, push image. So whenever the build completes, again, 30 seconds or so. So Quark was downloads lots of dependencies. So now my repository is empty. And once the action completes, we should be able to see the push image here. Pretty fast for a Java build. I was about to say, yeah, like... And free resources, you know. Usually with free hosting, I'm like, oh, this build's going to take an hour or, you know. Right. No, but it works quite well. So now it's in the push step. So you can see it's running here. And then once it downloads the JQ dependencies, you should see that the JIP build is starting. And then that the push step is also. So it completed successfully. We now move here. You can see that the image was pushed. And just a moment ago. So if we check the image content, we should see that the JIP core base layer and then the layers that we added on top of it. Okay, so next step, we want to deploy it into the developer sandbox. So probably you've seen this a lot of times in these OpenShift TV shows. We've mentioned it once or twice. Yeah, I'm going to mention it again. Just for good measure again. Yeah. Okay, so it's really cool because we can get to try OpenShift as developers. And this is my cluster. Right now it's clean. And one other tool I wanted to show today because it fits really well with what we are showing is the OpenShift, the OC login action to login into an OpenShift cluster that it's provided by Red Hat. So this is a Github action. And I'm going to add it and I will describe it. So basically, next step, authenticate with OpenShift. We need to provide these input variables, the server. This is provided as a secret, the token. So this is the one that you would get when you go here and copy login command. You would see that there is a token there and the server. So you would get those values and you can set them in the Github repository as secrets as we saw before with the Quake credentials. And I'm also going to set the name space because by default, whenever you login into OpenShift, it uses the code. I'm not sure why, but anyway, I'm going to set the name space too. And finally, I'm going to add the invocation to GQ. So what we saw before that Rohan did locally and in this case, generate the cluster manifest and apply them. And you can see it's a very, very simple pipeline, but it's kind of powerful because it's doing a lot of stuff. Again, push. If everything works, we should be able to see a new action invocation. New action, new build, new deploy, queued. So same as before. All right, we did the steps all of the times, but I think it's clearer, right? Does any of these build results get streamed back to your IDE? Or is there any back flow of communication? Well, that's more just a push. That's more up to if you might be able to configure more stuff with GitHub actions. I mean, the integration of GitHub with IntelliJ is pretty cool. But I mean, there are tons of things that you can do. I'm just showcasing how, like a very, very simple pipeline, but it's actually kind of powerful because with other tools, in order to do this, you would require a lot of I don't know, lots of configuration, lots of stuff. And you can see that this is working really out of the box for a recently bootstrapped Quarkus project. So again, now when you see the deployment, you will, I mean, it's kind of, for me, it's mind blowing. Okay, so now it's the authenticate step. So if everything goes well, this should succeed. And now the part where we are deploying to the dev sandbox. So if we go, if we go to the query repository, this should update to a few seconds. And here we are already seeing that we have the deployment. Okay, so if we open here, we will be able to see low, low open shift TV, just like we configured in the project. That's awesome. So yeah, the next step can be like very easily. I'm going to change the resource and, okay. So continuous delivery, right? So fifth, change the reading, let me tap push. Again, we should be able to see a new invocation of the pipeline. And when this completes, the result here should obviously change to the new value, right? I'm not sure if there are any questions that we can answer while this builds, but... Looking through chat. Yeah, same. I haven't seen any. I saw one earlier that's asking about the differences between the open shift plug-in and the Kubernetes plug-in. Right. Rohan kind of answered that in chat, but let's talk about it on there. Okay, so yes, I think I said this when we were introducing the project, but again, Kubernetes, maybe I'm plugging is the one you want to use if you are targeting any Kubernetes cluster, even if you want to target open shift. But if you want to use the more fine grained configurations or specifics for open shift, you should be using the open shift made on plug-in. So it, especially for the inner loop where you want to debug and do all of this stuff, it kind of makes more sense because the builds will run in the open shift cluster and lots of things that are more specific to open shift. However, if you prefer to use the Kubernetes made on plug-in to target an open shift cluster, there's no problem either. You will stick to the vanilla resources that Kubernetes offers. So this completed again and basically this should, yeah, so if I refresh and we can see the new message. I'm not sure if we have time, but we can also show if this doing this for native, but it will take like five minutes for the build. So I'm not sure if we have time for that, but basically adding another flag will enable this to create a native build and produce a native image. So Natali is asking in chat about the inner loop. What's the state of podman support for jcube? Okay, so podman with the new versions should be supported because basically if you, well, if you want to use it with this, you should install the podman docker tools. So it will basically be transparent. If not, we support podman by configuring the docker host environment variable, but this takes more work. So you need to actually start the podman in a given mode and then configure the host. So depending a little bit on how you want to, the complexity you want, if you just installed the docker, I'm not sure how the package is called, but if you install this docker toolset, it should work for you. Question in chat. Does native require corkis? Like is corkis a dependency? I don't think it is, right? That's a native? I'm not sure. I don't understand. I don't know what code Walla Walla defined native a little bit better, but is there any dependency on corkis at this point? No, no, no, this is basically, I'm using corkis to showcase how this works, but you can use spring, you can use even micron out now, so you can use whatever. Okay. I'm just going to set this just in case we have time. But yeah, there is no need to add to have corkis. JQ works with many different frameworks, spring boot, wide fly, I don't know, you name it. Even if you, even a standard Java application, which has nothing else, you can configure it and it will work. So no dependencies. Also, I would like to highlight that we don't depend on any CLI tools. So usually when you are using other tools, I don't know, any other alternatives to JQ that are not for Java, you need to install something, right? So for scaffold, you need to install their CLI or things like that. The nice thing with JQ and Java projects is that you can add it seamlessly to your project, like another Maven plugin, and you don't need to install any other dependencies. So that's kind of a great advantage in order to add. You can see that the pipeline here was really simple. We didn't need to set up any other things. Yeah, I really like this. If you have a shared release pipeline and you want things, different kind of core components hosted, this gives you a great way to showcase that and have certain shared assets beyond, in this case, hosted on Play. You could also swap in Docker Hub if you wanted to. We had two credentials to get into the Play environment, but there could be probably Docker Hub credentials if you wanted to go that route, right? Yeah, exactly. Is this tied? I guess so this is pretty tightly integrated with... No one else has GitHub Actions. That's a GitHub thing, I guess, right? Yeah, yeah, yeah. That's pretty... If there's an equivalent to other CI systems or something, but this is specifically a... GitHub Actions are the big plugins for the GitHub workflow execution. So it's the way that you can add functionality to these workflows. But if we review the pipeline here, I mean, this can be a big step in any other CI environment, Jenkins, Travis, Circle, anything, and it's very easily ported. So you just need to run a few maven commands. This is not, but obviously you could use OC login or whatever, or you could configure the OpenShell credentials using our plugin. I use this because I wanted to showcase this other tool and how well it integrates. But the pipeline is really simple. Also, if we check what we configured for JQ, as we said before, JQ impairs almost anything. The things we configured were more related to this being able to reload the latest tag in the cluster and things like that, but nothing specific for the application. So you can see that it's really, really easily configurable. So, okay. So I triggered a native build just in case we might have time to see how this pans out. But basically, to make it native, I just added a profile and a flag for JQ, and that's it. And it will switch to native. So that's kind of cool too. Nice. This is very nice. I like this. Any questions from the audience at this point? Just out of curiosity, get them in now before you have to jump to another show here in two minutes. Yeah, we got a wrap up. I like seeing, this is really, really cool, especially if you're a Java developer. I like seeing how this is progressing and the growth around GitHub actions. That action support gives it something kind of uniquely different from what I've have been seeing with the Odo command line tool and that kind of development pattern. One of the things I like from doing a Odo push is the build results are streamed back to your command line. Or you can tail a log of the build. And I know it's totally available in GitHub, which is even nicer because then, in a way, if I had a team of folks that I wanted to share those results with, this is maybe a more centralized kind of hosted approach for raising visibility on some kind of shared assets that you want to make sure everyone has access to. So for more advanced pipelines, this is really, really cool. Really cool. Really, yeah. Awesome. Cool. Well, I think we ought to move it on to the next show. Yeah. Thank you very much to all of our guests today. Go ahead, Chris. Yeah, thank you to our guests. Thank you, audience, for watching. We're going to be talking about a brand new project called SigStore up next on the Upshift Commons Hour with Karina. So look forward to that. SigStore is going to make signing images and signing things in general. A lot easier in life. So this will be a great show coming up. So thank you, Mark. Thank you, Rohan. I really appreciate you both coming on and seamlessly accounting for your power issues as well. Good stuff. Okay. Thank you very much for having us. Thanks. See you all next time.