 Hello everyone. Welcome back to another OpenShift Commons briefing. I'm Karina Angel and I am one of the OpenShift product managers and we're really excited to have John Bohannon from GitHub and John Dumovic here from Red Hat to talk about GitHub actions and OpenShift. They put a lot of work into this, so really excited to have them here to demo this for us. John, can you go ahead and kick it off? Yeah, absolutely. Thanks Karina. So everyone, welcome to this introduction of how to use OpenShift and GitHub actions. I'm one of the Johns that's going to be presenting today, John B. We also have a John D from Red Hat. So here's how we're going to spend our time together today. We've got about an hour together starting off at really the ground level. Like you've never heard of GitHub actions. Of course you have heard of OpenShift and we're going to go quickly into demos and then Q&A. So be sure to save up any questions you have for the end. Like I said, I'm John Bohannon. I'm in GitHub partner engineering with the background in hardware engineering and application development. And feel free to reach out after the talk to talk about partnering about GitHub platform, APIs, GitHub apps, GitHub actions and so on. My name is John DeWiewicz. I'm the experience architect for Outer Loop, which is everything in CI CD. So once it lands in Git and gets deployed, I'm responsible for what that experience is for developer tools at OpenShift. And you can see some of my history there. I'm a VM developer, but I always plug small talk because you got to go where the heart is. And let's get this show going, John. Yeah, that's right. Okay, great. So we'll start with GitHub actions. As part of it, it's the automation system that's built in to GitHub. So today we're going to mostly concentrate on its use as a CI provider, but you can use GitHub actions to codify any workflow. Just a few points on this slide. It is the number one CI provider on GitHub, which we're really pleased about after just a year or two of after launch. GitHub actions comes with a nice secret store for holding things like deploy keys, other credentials, and it's community and partner driven. So you get to build on the shoulders of giants like Red Hat. And actually, I like that you don't have to manage any compute to use it to try it out. You can just head to the actions tab of any of your repos, get started with a hosted runner and plug away. This is some of the terminology that we're going to be throwing around. So I just wanted to introduce you to it. Here on the right, I have a screenshot of what's called a workflow. This is just a YAML file and a special directory that GitHub actions looks in in one of your repositories that GitHub actions is set up for. And so in this workflow, I can write sequential or parallel steps that accomplish a task. In this example workflow, it's just like greeting newcomers to the repository with a message. But in general, I can trigger this sequence on any event across GitHub, like a pull request or a commit or an issue being opened or even on schedule or manually from a button press. So super flexible. My steps can be verbose and written right into the workflow. It can be bash or Python scripts, PowerShell scripts, or I can pull in a formal unit of work from what's called an action, lowercase action with defined inputs and outputs. And that's what Red Hat has developed and what we're going to be demoing today. I mentioned that GitHub actions is powered by the community and by partners like Red Hat. If you're someone who wants to write an action and give back to the community, you can write a JavaScript action. You can write an entire container image and publish either one to GitHub marketplace so that like 56 million developers can potentially discover it. It's a massive audience, a really flexible way to get into open source and to provide an interface to your tooling. What's also really cool is there's some official helper libraries like Actions Toolkit that help with grabbing inputs and producing outputs, making GitHub API calls, etc. So if that sounds interesting to you, don't hesitate to reach out to me afterwards and I can help you get started. I'm not going to steal too much more of John's thunder, but we're happy to announce today that several actually Red Hat actions are available for free in the Red Hat Actions organization on GitHub. With them you can easily use Builda, Quay, OpenShift, Knative, and a lot more. So Red Hat also maintains a starter workflow that you can find when setting up a new workflow and any of your repositories. But this is outstanding work that John's team has done and so who better to demo it than John himself. Now I'm going to turn it over to him for a set of demos and I can relinquish control of my screen share here. So as you do that, thank you very much for that intro. As sweet, we hope everyone likes our organization. We decided to go and not too many charts and just get to watching me run a demo. So that might be a bit of fun and games because it's live. We decided not to record anything. So the first thing I was going to do is show you where to look for more information. And so if you're interested in knowing what's going on in the Red Hat GitHub actions team, everything we do is here in public. You can sort of see what we've done already and released in terms of a build-a-build and those kinds of things. Our strategy here is to enable things that you know and love from the OpenShift developer tools ecosystem, things like build a S2I, other things, our Quay repository, those kinds of things, and make them available through GitHub actions and GitHub workflows because it's a really easy way to consume a bunch of the stuff and reuse a bunch of things you know and love from OpenShift. So you can see even things like our early release podman and those kinds of stuff. So if you're interested in what's going on, just join us here at the Red Hat GitHub actions org and ask questions or those kinds of things. And you can see we have quite a bit of stuff including Knative and a bunch of other things which I'm about to demo. So what we decided to do today is a few demos. The first one is quite simple. I created a simple app, called it simple app, and I'm going to show you how to enable this using GitHub actions workflows, the default OpenShift workflow and the developer sandbox. So basically what we're going to do is follow these four easy steps which is easily found in my repo. I'm going to get a sandbox which I did earlier. I'm going to go to the site. I've already prepped it. It doesn't take that long but I didn't want you guys to wait while I got a sandbox. But a sandbox is there and I basically, since I logged in earlier, it's still logged in and it's going to take me to my OpenShift cluster. So if you want to try OpenShift out, this is a really great way to get started. Then what I'm going to do is I'm going to take my app and I'm going to enable it to run this. Basically, I'll take you through a quick view here. I could just code, I'll just do it here. It's a really simple node app, nothing special. It's just going to serve up some pages. I have pages in my HTML directory so I'll show you what those are in a second. I have a very basic Docker file which is the pretty standard one. I have a little edition here so you can actually show what's going on with the demo, that it is a live demo and those kinds of things. And let's just get to business here. So GitHub is a really nice place to sort of add and get started with workflows. You can set up your own or you can go down here and take our ready set up OpenShift workflow, which I'm going to do. And so now I'm ready to, if I start this commit, I'm going to have a workflow, but it's not going to work yet because before you actually read all this stuff. So maybe developers don't read, but there's a few things you'll have to read. But what we did is we put these little arrows, like you're at the lawyer's office, signing documents on all the things you have to add for this to become executable. So I don't know where your username is, but I know what mine is. I don't even know how to spell my name most of the time. And that's my great.io username. You'll notice as I fill these in, I'm looking at things like what's this registry password and OpenShift server and OpenShift token. Those are things that you wouldn't randomly type in the clear here. So John mentioned earlier a secrets thing, a secrets facility to manage your secrets, so you could do something like put a deploy key and other things into secure storage at GitHub and then use it for something like a deployment. So that's what we're going to do, and I'll show you how we're going to set those up in a minute. I'm going to send this over to... And the reason I'm doing that is when I get a topology viewer, or sorry, when I get a new sandbox, I actually get three namespaces. Dev, code and stage, I'm going to be using all these today. But my dev namespace is empty. I put some cool future demo stuff here, so you'll see some of that stuff coming up. But right now I chose an empty one. So when I hit the topology viewer, there's nothing running there. So if everything goes to plan, and I find my workflow, which I'm right here, this will end up here in database dev. Now, due to an issue that we're fixing today, I have to go back to 1804, but that should be fixed in our update to the build. And I think that's it. I've decided 8080, I don't want to change the port. I want to change my app name or tag. And I can take you through a quick flyby of this workflow. So first things first, it's using some features like setting up outputs so that when I run this workflow, I'll get a really nice output to tell me where to find the app, but I just deploy it because I always find that very interesting. You get a bunch of automation, but you can't find where your app does. So if you use this and start to commit and just start running stuff, we'll warn you that your secrets aren't set, so you don't have to debug the thing. It'll tell you what to do. So we tried to make it very easy for someone who wanted to just try out GitHub actions and an OpenShift cluster to just go and type in some things. We're using our build to action, which is going to basically create an app and the current tag, which I computed with the SHA-7 of my GitHub commit. And then I'm going to push it to my registry, and this is where some of these secrets and things will go. I'm going to log into OpenShift and then I'm going to create and expose the app as I scroll down to the bottom of my window. So I'm not going to wait much longer. I'm just going to actually, I'm going to do one more thing. So before I do this, and I waste your time watching the registry password and token, I'm going to go over here to the settings. So the settings has a place on the right-hand side for secrets. I don't have any secrets. This is going to be a problem here because it's my first time enabling it. If I don't enable these secrets, I'm going to have the workflow won't run. So adding a secret is quite simple. As you can imagine, I can do something that I've done before. And trust me, I will fix this. But that's how you would do it from the UI. I'm UI-adversed in some cases. I like to automate. So I actually wrote my own set secret script, and lo and behold, it's going to go. And I'm already logged into OpenShift here. So it's going to query my OpenShift credentials and things like that. In this case, getting my login token and it's getting my server using some OC commands. It's also grabbing my conveniently environment variable docker password so you guys don't get to see me type it. And if I go back here and I refresh my window, you'll notice that I just set the server token and registry password. So instead of me typing those manually and pasting all that stuff, like I would have had to type in two passwords. So for demos, that's not the greatest thing to be YouTubing. So I did it with a script. So if I go back here now and I start my commit and I just give her, I have to wait very long. My OpenShift initial workflow is now running. So what it's going to do is it's just going to build and deploy to OpenShift. And if I decide to watch this run, it doesn't take very long to be honest. It's already done the tag. It's doing a build. It's sipping along quite quickly here. And as soon as the build is done, we'll see a push to the registry. John, I'm trying to make a quick building is the secret setting that you did from the GitHub CLI there in your script. Yeah, it's kind of a one-way C, right? So like we can put secrets into the secret store with API. Yes. But we can't get them out with API. So the only way to get them out is to run a workflow like you're doing here. So it really is a secure storage. Yeah, it is secure. And I'll show you the way I did this. You'll notice that I'm using the GitHub secret setter in the GitHub command line. So it's a convenient thing. If you haven't seen it, I recommend downloading it. If you use a lot of GitHub kind of things, you can set your secret, but there is no corresponding get secret. So if you forget it or don't know what it is, this is not a place to get it back. So as John says, it's one-way in and then, of course, available to workflows. So let's go see if this is done. It's close, but not quite cigar. It's pushing to the registry here, so this won't take very long. This is usually about a one-minute, 30-second total, depending on how the load is, although it's mid-day East Coast. So we'll see. And at that point, when we're done this fine first pass, we'll see an application running. And it'll be running here in the Jdemovic depth space. So that's the first part of the demo. Hopefully we don't have to wait too much longer. John, did you get a chance to play around with the GitHub? There we go. I was going to say that, but we can talk about that later. Sorry to get up what? Anyway, is this the CLI? So this should be deployed. And lo and behold, there's my app. It's starting. It's not quite running yet. If I click on it, it's container still creating. So it's going to download the container and run. This doesn't take very long. And as soon as the donut fills, we should be ready to show you the app. This app is a simple app which was designed to be a self-advertisement for this demo that we're doing today. It's kind of recursive. So when you run this app, you can find more about the actions. I showed you earlier. If you want to go back to our Red Hat Action site, you can go to the GitHub Action site as well. And, of course, together we're super awesome. And it tells you how two four easy steps to figure the same thing. And you can then, of course, link to the simple app, which is where I was doing all the work. So the whole thing is quite simple. Now, if I wanted to, and I wanted to fix something like here and edit instead of just clicking, I can run this again and then I'll show you an update later when we're as we go on to the next demo. You're welcome, whoever. And if that would be happy. And, of course, we'll see another build running in a few minutes. We'll see that running. I won't make you wait for that, but you'll see it took about two minutes and it won't take much longer this time. So the next demo I was going to do was something a little more complicated. People ask us a little bit about this. So I'll close these for now. So you don't have to watch all this stuff happen. This will be updated in the background. But the next demo I'm going to show you is, earlier today, I took our spring pet clinic demo and I did a demo release. I didn't update the database. I just did a quick demo. So there's no database currently running. I'll show you that little error message. But this shows how you could use your spring application to deploy to OpenShift. So I'll take you through that one. It's available in our Red Hat Actions org. I happen to have a fork of it so that I can have my magical set secret script so that I can easily whip through demos. That's convenient. And, basically, the interesting thing here is there's a few actions I want to show. One is we've decided to make this another demo showcase for how to use existing actions. So if you wanted to use one of these plain old Docker builds and push your image, you can peruse your way through here and show exactly how you would do that. In this case, we're actually using Builder for building with a Docker file. And, basically, do essentially a build of your image. And if I'm interested in S2I, we did a sample workflow there that shows you how to do an S2I build and pick the correct Java and those kinds of things. So if you're really interested in taking your spring application and learning to build it and learning to push it to an Opuship cluster, this is a place to look and learn a bunch of stuff about how we do it and how we recommend it. The demo, though, is going to show you that's interesting to me. I'm going to show you what I call using the cloud for my own good deeds. So, for example, I'm running on OpenShift and I have an instance running now here. And what I'm going to do is I'm going to deploy a second copy. I'm just going to go and take this for the OpenShift common stuff. Did I not change it? Where's my changes? Having demo fatigue here. Something funny going on. All right, that's supposed to change. This is a very weird thing. It is saying no changes to commit. This is not what I expected today. Is it getting ignored or something? It shouldn't be. It's given that this is the one I did last night to specifically do this. Anyways, demos are fun. So let's go try this the old school way. Find my location for this fine thing. You know, it's just the browser is slow. There we go. All right, let's push this now and not worry about it too much. So the browser or sorry, the VS Code finally determined it was changed. So demo. So I just did that and pushed it quickly. And you'll notice that because I have three different workflows they'll all start running at the same time. So I'm going to burn a little bit of my get up time here. And the one I'm really worried about is this one or paying attention to. Notice it's built in a bunch of different steps. So these first compile step, which is then a pre cursor for the build and push the quay. And then it'll deploy to openshift. So if we go back to our demo a little bit, you'll notice that we've built it based on this, you know, these separable steps. And the steps then can be dependent on a previous step using the ID of the steps. So you can have that workflow that we just showed here running as a sequence of dependent steps. Okay, so this doesn't actually shouldn't take that long as well. And when it finally finishes, while we're at it, let's go back to this. This one probably finished, right? See, the other were super awesome and so is openshift comments. So that was my previous demo. We're going to just stop with this simple demo. You can play around with it if you decide to try to find some time to just learn something new if you haven't seen actions and openshift together before. So click around here to get rid of extra stuff. So this one's still compiled and now it's building. This one will take a little bit of time. So I'm going to wait a little bit and I'll show you one of the reasons I really do like how I've been able to set up my workflows for demos and for day-to-day stuff. I've been able to incorporate workflows into just my regular projects and then loop in my sandbox. And so whenever I play around, I can always have a running copy of my application. So this is part of what I would consider leverage the cloud for a developer's use. And so while CICD is typically for, a lot of folks consider it prod or pre-prod, something you're going to deploy, I also consider it something that you end up using as part of your day-to-day development. If you want to see something a little more realistic as part of what's going to happen when you do finally get ready to start using a real cluster in your development and testing. And when this finally runs, we'll see a version of it hopefully. I just took, oh, am I going to be, that's the Docker build one. There's S2I. And now the one we actually care about is deploying. So hopefully if we can catch it live here, build's deploying. But the reason this is interesting is, we're going to have this one here, which I'm going to close my windows here and make sure I have it all ready to go. But I have this one here, which shows me, oops, wrong one. That's why demos are great. I have the old one, we would have never seen. Now I have two. So I have this one, which is coming up still. And I have this one, which is up. So this is the demo live one. And if I go back to this viewer, it's starting and if I go to my logs, I can actually see it's probably still bootstrapping a little bit, but we can always find out by clicking here and checking it. And there's the new version. So the reason I put this in the demo today was, I realized we had a discussion yesterday about demoing CICD can kind of seem not as exciting, but let's talk about how you would use this. One, here I have my two versions of the app running side by side. So if you don't incorporate, in my view, something like an OpenShift cluster or if you're developer Kubernetes, something like a test environment where you can run things like side by side, I can actually then have testers or even just developers go, what did the old one look like? Oh, look, and go to, this is a copy of the new one. Oh, look, that's different. And I can then run them side by side. When you do this locally on your local desktop, which you can do, you're ending up managing ports and you're changing your scripts to have multiple copies and then you can't run the same copy out of the same directory. You got to check it out multiple times. It's all sorts of stuff you end up doing manually. While here, there's a lot of things that just are kind of a natural way to do it in the cloud. And so I wanted to point that out. And if you're considering kind of using some of this stuff, considering incorporating these kind of new ways to validate your applications, and I found that GitHub Actions was a really easy way to do this because it's all part of my code base and I can just push in and go. So that's part of the spring demo. I don't think we're going to show much else because they did show a live change. And so while I'm at it, I'm going to take you to the third and final demo and just to make a few points on this one as well. So this one is what's called, an application called Griftuitus. It's hard to pronounce because it's a play on Griftuitus Graphics. It's the name of the application. And what it does is it's designed to show you could build slightly more complex applications. And so this actually existed before and when I started to GitHub Actions work last fall, we decided to see where we could take it and what we could do with it. This one's interesting. It has three different programming languages for a single service called Go, one for Go, one for Node, and one for Quarkus in Java. It's got a front-end load balancer that I inserted for convenience and it's got an Nginx for all the HTML stuff. And so in this particular case, that's this application here, actually I'm going to show you the application a little bit. The application is actually running and you can now, you'll probably figure out why it's called Griftuitus because it's using Griftuitus Graphics. These charts mean almost nothing because they're basically benchmarking the app itself so it really doesn't. And it just shows you some intergalactic numbers flying by and those kinds of things. You can play with a number of requests and stuff for performance and other testing which we can actually demonstrate lots of interesting things on the cluster like scaling and other things. However, today I'm just going to demonstrate a change. It's going to be applied dynamically and how the GitHub Actions that we put together work to make all of this stuff happen. So I'm going to go down here first. I've been using it already so I'll show you what I did one this morning. You can probably guess when I show you the last few action runs what I did to set up. That's a hint, yellow. Let's close some of these so that we're not going to get buried in windows and get rid of this one probably for now because I have one here and as you can probably guess, yellow refers to the color of the go implementation in the cluster which you can also see here. You can see the yellow but you can see that this is the application. And this is nice because you can demo if I decide to go for two pods. You can demonstrate that eventually you'll see, or three pods instead of two pods, you'll eventually see a third slice once it scales. So once you see this fill out, you'll notice that hopefully I can not too like. Anyways, we'll keep an eye on this for us while it's changing and I'm going to go down here and audience participation time close a bunch of these windows. Anyone want to pick a color? Anyone want to pick a color? In this case, just to... I'm going to first do the change and I'm going to take you through how this particular workflow works and then some of the things we have to do and show you some other features in GitHub that we were able to find. So the first thing I'm going to do is to my go application instead of yellow. Today we're going pink. Hello, hello. Hello and behold. So there's the three node, sort of the three go instances I earlier scaled up. If we're running autoscale and other things, you would see this happen automatically when we push it but that's not what we're doing today. We're just going to show some CI and CD. The action workflow I just... the workflow I just fired off was my commit for pink and so what's going to happen is this workflow is going to just do a very simple. This is actually the same workflow that we started with the OpenShift simple app. It's just cookie cutter, build multiple containers in case it's going to build the go one and lo and behold it's going to build and push it and it's going to skip some steps. So the skipping of the steps are what I was going to show you a little bit and I was going to show you one more thing or a couple more things. Simple app. I could get lost here in the demo but let's go here. So while we're doing this I'm going to do this here so you can watch. There's a slice disappearing on you maybe and look we've already built and deployed the pink and you can see the yellow is going to disappear as the deployment disappears and then the pink start to get the two deployments and I'm going to show you how all of that kind of works. So it's gratuitous graphics so you can actually watch something and I can talk to changes and you can actually visually see them without me going hey look I changed Hello World to Hello World Commons but I wanted to show you a few of the interesting things that we did here although I did want to point out a few of the interesting things. One is I regularly normally have my GitOps repo separate from my Dev repo but for convenience I made a mono repo for this demo and I put everything in one so I put all of the GitOps deployment yamls in one spot and I put all of my services in one spot and then finally you would put each service in a separate repo so they have independent life cycles and then you would have the GitOps repo that actually talks about the manifest and the configuration and all those things with a back end or a deployer like Argo CD would then also be used for taking that but I put it all into one and then I wrote this action to or this workflow to show how that could be done with images even if none of them needed to be changed so I added a facility to compute the changes which is your basic script using a diff and some repping, nothing spectacular you can see it. There is a bunch of GitHub actions that do properly detect changes so you could write an incremental builder I didn't do this because I also used this to incrementally build locally and I was using this script already to go and diff on my local machine and I used the same script on GitHub. If I was doing just the GitHub diff I would use the GitHub action and I can actually show you where that was we use it in a bunch of our Red Hat actions as a way to determine what to build for our demos and for our actions and so I selectively, this is a feature I can selectively run steps so just back to what you saw earlier you'll see some of these steps have a little didn't run because they didn't need to run I had a conditional step or conditional flow here so I could just build a bunch of them now the interesting thing here for this demo other than there's a bunch of things, a lot of complicated things going on is after I patched my images to have the new deployment so that's unfortunately this interestingly long thing actually that's not the interesting long thing there's a patched, this interesting long thing that will patch the images with their new names so basically this is an all in one script so I bring this up so you can go and look at it and figure things out but at the very end I interact with GitHub itself using an action that I found a fellow named Peter Evans who does quite a few interesting GitHub actions and after my pink was deployed which should be here, what's happened well the previous one was yellow and the current one was pink, well how does that actually work in a GitHub's workflow? I need to change my repo so what I did is incorporate into my workflow a fairly basic it's not super fancy action to send myself a pull request and that action will then of course send one and the let me see where I am here so there's the commit and you can see that I patched the old image to the new image and then if I'm happy with that deployment now if I was doing A, B, roll forward all those kinds of things there should be some automation but I'm showing this demo manually if I'm happy with this I can just take it and since it's all ready to go I can merge it happiness is me and I can delete the branch because I don't really need it and lo and behold my app is now going to match I have to go back to my local deployment I should see the old one here but if I pull back to get myself in sync I see it change hopefully you spotted that to the new tag so this is me running a full end-to-end CICD out of GitHub just for myself with the full GitOps kind of workflow to determine what gets released and I can go back to any previous release and it's all tagged through these pull requests so just the power of the cloud is really the message you're using CICD as part of your everyday workflow just because it gives you a lot of interesting kinds of things you can you can do so those are the demos we are going to basically run through today and I was going to just end with a couple of things and then go back to some charts and then we can go to the questions and we'll have plenty of time I hope if there's any good questions we'll see I wanted to I wanted to point out stuff we haven't demoed and then we'll talk about it a little bit today we built also if you want to run for open-shift users who may want to run an action or workflow on their own self-hosted cluster on their own cluster they can install these pre-built images there's an installer here for this there's an open-shift action runner chart so this chart here is a help chart which will allow you to install and run any runner on your local cluster so if you want to do some of this stuff and for some reason you feel it's something you'd like to run on your cluster now in some cases maybe you don't want to do the build on your cluster but you might want to do some testing on your cluster which is already pre-configured this is the perfect way for you to get GitHub to launch and execute on your cluster the nice part about this particular case you can also the nice part about this particular case is I can also use this with other open-shift or red hat tools like code-ready containers which runs on my desktop I can also wait for work from GitHub and I could be doing things like running testing and other things so if you're interested in this workflow I encourage you to go and look at the runner chart there is some samples that will show you how to do this but basically you can install a runner it will pull back to GitHub and it will show you it will take work whenever you run them on GitHub it's pretty nice and if you want your cluster to be part of your own personal cluster or something as part of your dev cycle that's a great way to do it and it works with things like our CRC on the desktop the other stuff I wanted to point out we didn't demo today but it's a great way to learn we have Knative integration and so we've done some actions so what we're trying to do is ensure that there is a standard consistent way for you to use GitHub actions with open-shift a very natural set of and we try to make consistent namespaces consistent secret names so once you've learned the stuff for example from the starter workflow you can use that knowledge later so I encourage you to go and see some of this stuff you may not be able to use the Knative with the sandbox yet but if you have a cluster that can run open-shift serverless you should be able to try this one out and get yourself going the Spring Pet Clinic of course this is where I forked mine to show you the demo today I didn't really do a lot of work other than forking it and filling in some secrets in a little script a bunch of direct actions for talking to open-shift and there's one more I really want to talk about here as soon as I scroll past it that puts a little bit of thought into it this one here so GitHub comes with a large set of pre-installed binaries in their GitHub hosted runners which are really convenient because you don't have to install them it's instant, it's fast you can just use them so that's really great now for anyone here who's a DevOps engineer from way back or managing builds or has been burned by changing versions of tools underneath them who installed this new compiler is the screaming you hear from the build engineer someone responsible and so what we did is we wanted to ensure that there was a way for you to get what I call a consistent lineup of all of the supported open-shift CLI tools into GitHub actions workflow and so this here is typically going to be the very first thing you put in your build scripts or tools because then you can control exact versions and you could say latest if you like but the exact versions of all of these command lines so that if you're build is sensitive to versions or if you're tied to an older version of open-shift or a different version and you need the exact, exact CLI lineup this is a way to do it and it's a standard way you don't have to go around and figure out where the downloads are so it's a really convenient way because in the real world where I need version X and I just don't know where to find it I've got to rummage around the mirrors and those kinds of things to find it in theory the real world in an ideal world you wouldn't need to be versions dependent but in the real world you're often tied to a version so we have this model where you can install the correct lineup and we optimize so if GitHub has the correct binary that you're asking for and you wanted to ensure that your versions to that version then you can actually use this and you can find one or more command lines and this is our strategy for ensuring that any command line that you can get from Red Hat through for example the command line tool installer which comes with every open-shift you can also incorporate into your GitHub workflow so we don't want you to be rummaging around here and doing manual stuff we want to make your day-to-day a lot easier and that's what we've done for that I want to make sure I mention that because it seems like a small thing but it's saved my butt a few times where I just a new release of something came out and I wasn't prepared for it so I had to go back so with that I think we're done except for this cool so I did want to go through this just quickly and then questions I think we did our timing just right John so this is our roadmap with vague near-term mid-term long-term meanings I do want to point out if you've watched me scroll through all this stuff we've pretty much completed everything in the near-term and we're going to move on to the midterm our near-term goals were basic authentication deployment, CLI installer which I just showed you, CLIs that are specific to build Knative and all in the marketplace very much bootstrapping we have a single user runner which you can install via that help chart so that's there and we're working still this is coming at some point fairly soon on a single user bot that you can install on your OpenShift cluster and that will manage those secrets for you that I was so instead of you having to type in my version of this which queries the server I'm going to and queries the server for the token it's going to do it for you and you won't have to bother with all that so we're trying to make that user experience very simple the midterm is around being able to build on, build things that require entitlements, testing better scanning and other security DevSecOps kind of integrations VPN to private clusters is something we're exploring and in a bunch of other things where you can re-leverage things like Tekton which might be important if you're an OpenShift user with GitHub as we call it a bit of our shift left because if you're already running it with a pre-built task on your cluster you might want to also give it a go on GitHub looking at operators to make it a lot easier to manage things like the runners because you might have lots of them and integration a little more integration to Sandbox right now you'll notice again I had to manage these secrets and other things we wouldn't mind making it a lot a lot smoother experience to get a Sandbox and work with GitHub so hopefully in a future demo you won't watch me click around a lot you'll see just smooth getting stuff built and deployed and then of course in the longer term execution on pipelines on OpenShift pipelines so if you want to actually leverage the OpenShift cluster be configured for security or be configured for larger things larger heaps, larger memories that might be available on GitHub. Look, GitHub is very generous with their 7GIG that's pretty much big enough for anything however there are things that do exceed that and then some other UI things so if you're building on GitHub maybe the status in the OpenShift console that's attached to that app will be up to date and consistent and then a few other things for integration to our GitOps which is coming out this year which is of course naturally something you would layer on top of Git. So that's it and now John you won't, I don't know where who put concerns in here but I left it. Concerns? Anyone concerned about the direction you take? Questions I like, comments I like I'll take concerns but it was I used to just direct them to your personal email but I took that out too so yeah. Well there, so that's it for us I think in terms of all the things we wanted to show and sort of things to bring up so we'll take questions and I haven't looked at the chat or anything like that to see if there's any but Serena's going to or sorry wrong Ena sorry I'm going to stop sharing as well unless I can see you all. I will ask you probably to put that roadmap slide back up in just a minute. So quick question is it currently possible to submit requests are these actions still in the early stage and how my follow up question to that is how and where do you send the request to and feedback so I guess you're asked this I'm going to interpret those two questions one request to GitHub to extend GitHub actions in some way and then requests to Red Hat to extend our actions in some other way is that correct I'll answer the Red Hat one which is you go to the Red Hat actions org where the link is that I've been demoing and create a new issue of what you want as a feature and we'll prioritize it in our planning which is done in a project on that organization so if you have a feature request or you want to anything that you want to talk to us about we hang out on GitHub as you'd expect I just followed up with a a pointer to the contact support GitHub support link GitHub wide feature request that's the central funnel for all requests like that nice and for those of you watching and don't see the chat it's support.github.com slash contact straight to John. No, not really. Okay, yeah, that's me. I'll send you his email too. Another question, could you please describe the limitations for GitHub actions with OpenShift when you're running behind the company's firewalls? Great question. Yeah, so the issue is that if your cluster is not reachable which is essentially your problem then some of the actions that directly log in like O.C. Login and O.C. Any command line that talks to the cluster needs reachability. So you understand the roadmap there was a VPN feature we're looking at what it would take for you to enable a tunnel from GitHub back to your private cluster but only for you which would then then let you treat your private clusters just like just like something on the public Internet but it wouldn't go through it doesn't need a public DNS. So that's the downside of having sort of stuff behind the firewall. There's two use cases that we've seen however one is a lot of customers who have GitHub Enterprise, they're on the correct side of the firewall when they run actions or when they, if they're having actions running at GitHub Enterprise. So they're on the correct side of the firewall so a bunch of this stuff will still work in an enterprise kind of context and then the last point I want to make is things like the GitHub runners are a outward connect model. The runner runs and talks to GitHub and waits for work. So you can still use for example on your desktop or code ready containers receiving work on a private cluster or any private cluster receiving work from GitHub because the model is a pole model not a push to the public DNS. Okay. Thank you, thank you. And in the chat there's a proxy server model but it's still investigating what the best way to do it is because as you could imagine security is a problem. Concerned for a lot of folks who don't want to just punch through their firewalls. Yeah, I'm glad you posted the link to the proxy server and question is, I know you're looking into it John D but does it work right now have you tested that or at least tried it out using the proxy server I'm sure there's some people have tried it we have we haven't but the links that's reference is talking about outward proxy so a lot of enterprises need a proxy server configured for outward connections and so if you want your runner to talk to a proxy server to get out that's what this looks like I'm talking about from GitHub itself how it's I would talk to arbitrary behind the firewall server which is the other direction thanks because I know we'll have that's going to be one of the top questions right that you always get asked that's one of the bigger problems we see it for even things like web hooks for example CC redirectors to go from and then of course you have SSL issues because you don't want GitHub needs a secure connection to post web hooks it's the same essential problem of having a public service talk to private behind the firewall networks I think we'll look at it from the GitHub context initially but I think there should be a better way in general to allow that especially with ops control to make sure that all the security issues are taken care of but I think it's yeah go ahead John no I was just going to ramble on a little bit because you know about the ops folks who really need to know all the holes punched in their firewalls to get to essentially what they consider our developer use cases which may not be a high priority so yeah I know we have a mixed audience today so I just wanted to point out that there are a few different variants of GitHub there's like the GitHub.com version that's free to use there are different paid tiers of that as well including an enterprise cloud and GitHub actions is available on all those and also the on-premise GitHub enterprise server so it's worth trying out in that context too yeah so yeah so if you if you have enterprise with actions and you want to try our actions one of the things that we we're trying to ensure is that we work transparently with enterprise and GitHub.com the public sass the only real difference is the API endpoints so you have to you know sort of the only the major difference is the API endpoints everything should work as long as you're considerate of the environment that's it's being run in so if there are issues you try it out and you find issues call me and we'll figure out what the real how to fix that quickly or what the fix has to be because we do intend it to be like one right once and run pretty much anywhere you have the yeah and there's a detail there that if you're on GitHub enterprise server you're not going to be able to reach out to public actions like red hats out of the box you need to enable a feature called GitHub connect and you can Google the documentation for that I can't do two things at once right I would do that too but get up connect will allow you to say you know red hat actions slash you know OCE installer and use those thank you John B can you talk about github apps just really quick you know you highlighted in the yeah totally funny mention that I just wrote an introductory article on on dev2 yesterday get have apps and get have actions work together well they're both programmatic ways to you know integrate and interact with github APIs if it helps clarify github actions is itself built using github apps so github apps came first around 2018 it's a way to scope and control api requests to to github but if you have any further questions please let me know yeah so I can comment a little bit on that from a roadmap perspective so github app has a very nice way to give you fine-grained control access to your github repository or organizations you could have an app that says I just need repo access or I just need access to workflows so it's essentially a way to create bots for yourself to do things autonomously and the install experience is quite easy I have a prototype but I think we're going to have to save that for another another excellent teaser for the next one you go off into github install the app and all of a sudden you have another assistant over your shoulder doing things automatically for you and in our case the first use cases would be once you install this we'd like it to manage your workflows and the secrets and all the things we showed you in the github actions from the Red Hat team for you so that you're not looking around and go what did I forget to set because you should have seen these demos in the early days I'd forget to set the secret and then I'd have to do it twice and you'd watch me debug for a while automate all of that so the experience is very smooth in using the two together but only with the rights that are needed as opposed to a full OAuth token which is pretending to be you and only you which has unlimited power so it's a really nice way to have scoped access and it does a lot of automation and bot like things so you could have one for secrets management you could have one for auto comment and closing issues and other things that are good policy things it's very powerful and the first one we're doing is running in your own work spaces your own name space and eventually when that becomes something that's a little more robust we'll look at making it something that works across the works Exactly and github apps also have their own identity so they don't like consume a seat in your enterprise instance and they can also take or they can be permitted to act as the user so you can send a github app user through the OAuth flow and do the normal OAuth dance and do something that pretty much everybody is familiar with but it's a flexible model I encourage you to check it out so no the image is not available sorry Karina you should probably I'm reading the text for those that don't see the question might be the wrong form but does github have any plans for delivering OVA templates for the github runners I can't speak to the plans the build scripts that we used to make those VMs are available I just sent a link to the virtual environment action slash virtual environments repository where all that happens but I don't think the image itself is available right now I want to say it's for licensing reasons of the software that's included but I'm not sure on that maybe we'll find out for the follow up and with one minute to go do either of you have any posing thoughts really great demos I just want to say that again no others have also commented on how great the demos are so thank you what's nice to hear we we actually met yesterday to talk about the kinds of messaging and demo kind of stuff so it was good to hear that the discussion was useful for everybody but yeah CS on CS on our red hat actions github so if you need to know things or want to know things you can always of course I work at red hat so if you're from red hat you can find me I'm sure but I'm pretty easily accessible so anything you need to know I can certainly find find out stuff for you if you want so but thanks for the feedback on the demos we're trying to make them kind of useful and not just watch me run something yeah I think you did a great job John thanks for all the teamwork looking forward to the partnership and I'm looking forward to the next session we'll line that one up thank you everybody else for joining us today and this will be posted to the open shift YouTube so look for it there and thanks again for joining us and Chris can you see us out