 Hello, everyone. My name is Chris Kang. I am a specialist solutions architect at Red Hat. Today, we're going to demonstrate a Play-Go software pipeline on Azure Red Hat OpenShift, and we'll trigger that pipeline using a GitHub action. The first thing we'll need for our demonstration is a Azure Red Hat OpenShift cluster. You can see here in my Azure console that I've already gone ahead and deployed an Azure Red Hat OpenShift cluster. If we click on that cluster, you can see more information about this, such as the location where it's running in US East, as well as the version of OpenShift that's running. In this case, it's 4.5. In order to deploy the Play-Go software factory, we need to enable the Play-Go software factory operator. So the first step is to actually add this catalog source. You can find this under the operator documentation, and this will make the operator available in our operator hub in the cluster. I've already gone ahead and applied this against the cluster. Next, we'll navigate to the OpenShift console. As you can see here, I've logged in under the Kubernetes administrator account, and now we're going to go ahead and deploy the software factory operator. First, we'll create a new project. We'll call this DevSecOps. Next, we'll navigate to operator hub, and if you scroll down to the bottom left, under provider type, you'll see Red Hat, North America Public Sector Community Operators. This is the catalog source that I applied to the cluster. If you select this provider type, you'll find the Play-Go software factory operator made available to the cluster. Let's go ahead and install this operator. We'll install this in the DevSecOps project that we just created. Now we'll install this operator, and we'll take a short break and come back after this operator is installed. Okay, the Play-Go software factory operator has been installed, and the next step is to deploy the Trusted Software Supply Chain platform. We'll go ahead and select the platform API, and we'll create an instance of the platform. If you look at the YAML view, you'll see that Jenkins is the underlying CI tool for the platform. We'll keep the defaults and create this platform, and it'll take about 10 minutes, so we'll take another short break and return after the platform has completely installed. Okay, the Play-Go's Trusted Software Supply Chain platform has been installed. If we navigate to workload pods, you can see the various pods of the components that have been installed as part of that platform. And another place to get a really good overview of these components is under networking routes, where you can find the externally accessible URLs of the various components within the platform. Now the two that we're gonna focus on in this demo today, one is GitT. GitT is a local Git repository that will host our source code locally within the OpenShift cluster. And the second is Jenkins. So Jenkins again is a CI tool that will orchestrate our Trusted Software Supply Chain pipeline. Now before we deploy our sample pipeline, we need to give our pipeline the location of our source code application. So the source code that we'll use today is housed in my local GitHub repository. This is a reference application built on top of the corkis runtime. So navigate to the command line interface. I've gone ahead and constructed this pipeline in YAML format. And as you can see in this YAML, I have specified my GitHub repository as the source URL of the location of the source code of this reference application. Now I can apply this pipeline and I've already deployed this pipeline before, so it's been configured. If I navigate to my OpenShift console, the pipeline already exists and has been configured. Now when the pipeline is configured, the first step that it does is it clones my GitHub repository, which is this source code here, and it'll clone that into a local GitT repository that sits inside of the OpenShift cluster. So if you go to networking routes, we'll navigate to GitT, and you can see a local copy of that source code existing within our GitT instance, hosting that exact same source code. In addition to this, the trusted software supply chain pipeline automatically configures a webhook so that every time a change is pushed into our local GitT repository, it will trigger the software pipeline using Jenkins. So now we wanna trigger this webhook in this pipeline, but we wanna do it from our GitHub repository. So in our GitHub repository, we're gonna use a GitHub action. That GitHub action can be found in this YAML file. And what this basically says is every time a change is made within my GitHub repository, I want that change propagated down to my local GitT instance, which then triggers the software pipeline. So if I go ahead and navigate back to my command line interface, I'm gonna go ahead and commit that change, that GitHub action into my source code repository. Now once I push that change to GitHub, I should see a GitHub action get triggered to mirror that change down to my GitT repository. So I'll navigate to my user interface, and we'll go ahead and take a look at my GitHub repository and under actions, we should see that commit and that is triggered a new GitHub action. And we'll wait here for a couple of seconds where it'll clone the change that's been made and push that down to our GitT instance. Okay, so the GitHub action has successfully executed. And if we go back to GitT, we can see that same commit has been propagated down to our GitT repository. And in turn, this change has now triggered our software pipeline in Jenkins. So we go to networking routes, navigate to Jenkins. Under platform, we see that a new build is now in progress. A software pipeline has been kicked off. So we'll take a short break and come back as soon as this pipeline is complete. The pipeline has now been complete. And you can see here in the second pipeline that has gone through that entire pipeline and deployed our artifacts into both a test environment as well as a production environment. So we'll navigate back to the OpenShift console and let's access that new application that was deployed. So if we go into our list of projects, if we scroll down, we'll see our reference application being deployed in separate projects, one for test and one for production. If we go into our production project, we'll see that we have one deployment. Deployment references the new reference application that was deployed. In order to access this, we'll go again to networking routes, copy this URL. If we look at the fruits HTML page, we'll now see that the reference application has successfully deployed. That concludes our demonstration of the Poligo software pipeline on Azure Red Hat OpenShift cluster using GitHub Actions. Thanks for watching.