Build a Self-Healing CI/CD Pipeline with AI

[00:00] Stop manually debugging your code and [00:02] discover how to leverage AI to [00:04] automatically detect, analyze, and [00:07] resolve CI/CD pipeline failures. In this [00:10] course, you will learn to bridge the gap [00:13] between DevOps and automation by [00:16] integrating N, OpenAI, and GitHub [00:19] actions to create a fully autonomous [00:21] self-healing workflow. [00:23] >> Hello everyone, this is Fzini, founder [00:26] of the techine. Today I am going to show [00:28] you how to build a self-healing CI/CD [00:32] pipeline from scratch using NAN GitHub [00:35] actions and AI. We will create a system [00:38] that automatically detects failures and [00:42] opens up all requests to apply the fix. [00:45] No more manual debugging. Let's get [00:47] started. Before we jump into the [00:50] implementation, let's first cover some [00:53] important fundamental concepts so you [00:55] have a clear picture of what we are [00:58] building. Think about this. It's 3:00 [01:00] a.m. and your build suddenly fails. [01:03] Normally, this means you would have to [01:05] wake up and spend hours digging through [01:08] messy, complicated logs just to find the [01:11] error. The reality is a lot of these [01:14] failures are just simple typos or [01:17] obvious bugs. Yet every minute your [01:19] pipeline is down, it's costing the [01:22] business time and money. This manual [01:24] debugging process is exactly what we [01:27] want to eliminate. That's where a [01:30] self-healing CI/CD pipeline comes in. [01:34] Instead of manual searching, AI catches [01:36] the error the second it happens and [01:39] performs an instant root cause analysis. [01:43] But it doesn't stop there. The system [01:45] actually generates a patch and opens a [01:48] pull request for you. This keeps you, [01:51] the developer, in total control while [01:53] the AI handles all the heavy lifting. To [01:57] build this, we are using a powerful tech [02:00] stack. First we have git and github to [02:03] manage our code and host our [02:05] repositories. Then we have nitn which [02:09] acts as the brain of the entire [02:11] operation connecting all our tools. And [02:14] finally we will be using cicd pipelines [02:18] to automate the whole build test and [02:20] deployment process. So how does it all [02:23] actually work? Here is the flow. First a [02:26] GitHub action fails during a build. That [02:29] failure triggers a web hook which sends [02:31] a signal directly to our niten workflow. [02:35] Open AI now steps in to analyze the logs [02:38] and identify exactly what went wrong. [02:42] Once the fix is ready, the GitHub API [02:45] creates a new branch and pushes the [02:47] corrected code. Finally, you get a [02:50] notification to review and merge the PR. [02:53] It's that simple. All right, enough with [02:56] the theory. It's time to get our hands [02:59] dirty and start the practical work. To [03:02] build this self-healing pipeline, we [03:05] first need to set our environment with [03:07] Git and GitHub. First, let's head over [03:11] to Google and search for G download. [03:14] Click on the very first official [03:16] website. And from here, simply download [03:20] the version that matches your operating [03:22] system. Once the download is finished, [03:25] open the setup file. Now the [03:28] installation is pretty straightforward. [03:30] Just keep clicking next through the [03:32] default settings until it starts [03:35] installing. While that's installing, [03:37] let's look at GitHub. This is our [03:40] version control hosting platform. If you [03:43] don't have an account yet, just search [03:45] GitHub and sign up. It's a very simple [03:49] process just like creating an account on [03:51] any other website. Now that git is [03:55] installed, we need to connect our local [03:57] machine to our GitHub account. For that, [04:00] go to your desktop, right click and [04:03] select git bash here. First, we will set [04:06] our username. So, type get config dash [04:12] global user.name. [04:15] And here you need to type your GitHub [04:17] username here this one. So I am writing [04:20] here fzine dash ali and press enter. [04:25] Next we will configure our email. Type [04:28] get config dash global user. [04:34] And here you write your email address. [04:38] Make sure you use the same email address [04:40] you use to create our GitHub account. [04:43] Press enter. [04:45] To make sure everything is set up [04:47] correctly, let's run get config double [04:51] dash list command. And as you can see [04:54] right here, our username and email are [04:57] correctly configured. Press Q for quit. [05:00] And now we can close Gitbash and move on [05:03] to the next step. Now that our [05:06] environment is ready, let's build a [05:09] simple NodeJS and ExpressJS project. To [05:12] start, I will right click on my desktop [05:15] and create a new folder named my dash [05:19] project. Of course, feel free to name it [05:22] whatever you like. Next, let's open this [05:26] folder. Right click and select open with [05:29] code. This will launch our project in [05:32] Visual Studio Code. If you are using a [05:35] different code editor, that's totally [05:38] fine. But I will be sticking with Visual [05:41] Studio Code for this tutorial. Once [05:44] inside, let's create a new file and name [05:47] it index.js. [05:50] This will be the main entry point for [05:52] our application. Now let's head over to [05:56] the terminal and open a new terminal [05:58] window. Here we are going to run npm [06:02] initate minus y. The minus y flag [06:05] basically says yes to all the default [06:08] settings. Wait, if you get an error [06:11] here, it probably means you don't have [06:14] NodeJS installed. In that case, just [06:17] head over to the Google, search for [06:20] NodeJS download, go to the official [06:24] website and install the latest version [06:27] according to your operating system. Once [06:30] that's done, you are good to go. As you [06:33] can see, we have a package.json file. [06:36] This is the most important file in your [06:39] project. It contains all your project [06:42] details and tracks every package we [06:45] install. If this file gets messed up, [06:48] the whole project could break. Now let's [06:51] install our web framework. In the [06:54] terminal, run npmi, which means install [06:58] express. This will install ExpressJS in [07:01] our project which is a powerful and [07:04] popular backend framework for NodeJS. [07:07] Look at our sidebar. Now we have a [07:10] package-log.json [07:11] file which tracks the exact version of [07:14] our dependencies and there is this [07:17] massive folder called node modules. This [07:20] is where all the libraries and packages [07:23] we use in our project actually live. [07:26] It's heavy but it's the engine under the [07:29] hood of our application. Now that our [07:33] packages are installed, we need to [07:36] define some important commands for our [07:38] project. Let's open the package.json [07:41] file. Inside the script section, we are [07:45] going to add two very important lines [07:48] which is test and build command. So I [07:50] copy this and paste it here. The build [07:54] command is what we will use to run our [07:57] main application while the test command [08:00] is what our CI/CD pipeline will use to [08:04] verify if our code is actually working [08:07] or not. Press Ctrl S for save and close [08:10] the package.json file. Next, let's [08:13] create a new file named it test.js. [08:17] This is going to be our smoke test. I am [08:21] going to paste this test.js code here. [08:26] And let me quickly explain what's [08:28] happening. First, we are setting a [08:30] express server on 5,000 port. As soon as [08:34] it starts, we use the HTTP method to [08:38] send a request to ourselves. If we get a [08:41] status code of 200, which is okay. It [08:45] means the app is healthy, the test [08:47] passes and the process exits with zero. [08:51] If anything goes wrong or the server [08:54] does not respond, it exits with one [08:57] which tells our GitHub action that the [08:59] build has failed. This is exactly what [09:03] will trigger our selfhealing process [09:05] later. Now press Ctrl S for save and [09:09] open index.js file. Type a simple line [09:12] here console.log log and inside the [09:16] console.log we can type anything like [09:18] hello from index.js [09:21] and ctrl s for save. In a real world [09:24] scenario this is where your entire [09:26] backend logic would live. For this [09:29] tutorial we are keeping it simple so we [09:32] can focus on the automation part. By the [09:35] way you don't worry about the copying [09:37] all the code manually while watching. I [09:40] have provided the link to the complete [09:42] source code in the description box [09:45] below. You can grab it from there for [09:48] your practice. All right, let's make [09:50] sure everything is working as expected [09:54] before we move to the cloud. Open your [09:56] terminal and run node space index.js. [10:02] Perfect. As you can see, it's running [10:04] successfully. Now let's test our smoke [10:07] test logic by running node space test.js [10:12] and press enter. And there it is. A [10:14] smoke test passed. Our local environment [10:16] is solid. Now let's get into the heart [10:20] of this project which is building the [10:22] CI/CD pipeline. Continuous integration [10:25] continuous deployment pipeline. We are [10:28] going to implement this using GitHub [10:30] actions which allows us to automate our [10:33] workflow directly within GitHub. To get [10:36] started, we need to follow a specific [10:38] folder structure that GitHub recognizes. [10:42] In your root directory, create a new [10:45] folder named [10:47] GitHub. Inside that create another [10:50] folder called workflows. [10:53] Okay, so I am writing here workflows. [10:55] And finally, inside the workflows [10:57] folder, create a file named main.yml [11:01] and press enter. This YL file is where [11:05] we will write the instructions for our [11:07] pipeline, telling GitHub exactly when to [11:10] run our test and what to do if they [11:13] fail. All right, let's write this line [11:16] by line. Follow along with me. We start [11:20] with the keyword name then a colon and [11:24] we will call this CI pipeline. [11:28] This is just the label for our workflow. [11:31] Next, we define the trigger using on [11:35] followed by a colon. This tells GitHub [11:38] when to start the engine. On the next [11:41] line, we indent and type push with a [11:45] colon. We want this to run on every code [11:49] push. On the next line, indent again and [11:52] type branches [11:54] followed by a colon. We need to specify [11:57] which branch to watch. Add a dash here [12:01] and type main. Now this pipeline is log [12:04] onto our production branch. Now move [12:08] back to the start and type jobs followed [12:11] by a colon. This is where the actual [12:14] task begin. Indent and name our first [12:18] job build dash end dash test then a [12:23] colon. This is our primary validation [12:26] step. Next line indent again and type [12:30] runs dash on then a colon and type [12:34] Ubuntu dash latest. This tells GitHub to [12:38] give us a fresh Linux server. Now next [12:42] line type here steps followed by a [12:45] colon. Then next line add a dash space [12:49] and write here name with a colon and [12:52] type check out code. [12:56] This is just a label for the first step. [12:59] Then press enter. Under that type uses [13:03] colon actions / check out at the rate v4 [13:08] means version 4. This is a pre-built [13:12] tool that pulls our code into the [13:15] runner. Then press enter. Next step [13:18] again dash name colon and write here [13:22] setup node.js. [13:25] We need to prepare our environment. Then [13:28] press enter. Type uses colon and [13:32] actions/ [13:34] setup dash node at the rate v4. this [13:38] install NodeJS for us. Then press enter. [13:42] Type with followed by a colon. We need [13:46] to pass a specific setting here. Press [13:49] enter. Indent here. And then type node [13:52] dash version with the colon. We are [13:55] using the latest and stable version [13:58] which is 20. Press enter for the new [14:01] step. dash name colon and write here [14:05] install dependencies. [14:08] Time to get our libraries. Type here run [14:11] and colon and the command npm space [14:15] install. This downloads everything we [14:18] need. For next step again press enter [14:22] dash name with colon. Type here run [14:26] test. This is the moment of truth. type [14:30] run with colon. And for the test [14:33] command, we need to write here npm space [14:35] test. If our code is broken, the [14:38] pipeline will stop right here. And for [14:41] the final step for this job, we need to [14:44] write here dash name colon and write [14:48] here build space project. For build [14:52] project, press enter. write run colon [14:56] and write npm space run space build and [15:00] add the flag double dash if dash present [15:05] so it does not error out if the script [15:08] is missing. Now let's build the [15:10] emergency response job. Go back to the [15:14] same level as our first job and type [15:17] notify dash n-on [15:22] dash failure. then a colon just like [15:25] before type runs dash on colon nubunt2 [15:30] dash latest then press enter type needs [15:35] colon space build dash end dash test [15:40] this job to wait for the first one to [15:43] finish then press enter type here if [15:47] colon failure open and close the bracket [15:51] this is the magic line. It only triggers [15:54] if the build fails. Then press enter. [15:57] Type steps followed with the colon. Add [16:00] a dash name colon and type trigger n [16:06] web hook. Then indent here type run with [16:10] colon and the pipe symbol. This allows [16:14] us to write a clean multi-line command. [16:17] Indent here type c space dash x space [16:23] post. Then in double quotes type dollar [16:27] sign. For the dynamic values type double [16:30] curly braces and then type secrets dot n [16:38] web hook [16:40] URL and then end it with a backslash. By [16:44] the way, we use secrets here to keep our [16:47] sensitive URLs hidden from the public. I [16:50] will show you how to set these setup in [16:53] GitHub settings later. Then press enter [16:56] here. Type dash capital H and then in [16:59] quotes type content dash type with colon [17:04] space application / JSON and then [17:09] another backlash. Then again type dash [17:12] capital h in the double quotes type x [17:16] dash web hook dash secret with the colon [17:20] and then type dollar curly braces type [17:23] secrets dot n [17:28] web hook [17:30] secret and add a backlash again here and [17:34] then press enter. Again we are using a [17:37] secret for the token to ensure only our [17:40] authorized pipeline can talk to N8N. Now [17:44] type dash with D and then a single quote [17:48] and open curly braces. Type here run ID [17:53] with the double quotes and outside the [17:56] code write here colon. Inside the double [17:59] quotes type dollar double curly braces [18:02] space and write here github dotr run [18:07] id. After closing the double quotes type [18:09] comma and press enter. Then again open [18:12] and close the double quotes. Inside the [18:15] double quotes write repo with colon and [18:19] then double quotes dollar double curly [18:22] braces github dot repository. Write [18:26] comma here and press enter. Now double [18:30] quotes open and close. Inside the double [18:32] quotes write here branch with colon and [18:36] then double quotes dollar curly braces. [18:40] Inside the curly braces write here [18:42] github dotref [18:45] name for the branch and after that type [18:48] comma here and press enter. Type double [18:51] quotes commit with colon. Again type [18:55] double quotes dollar double curly braces [18:58] double curly braces and inside the curly [19:01] braces for getting the commit we need to [19:04] write here github.sh S H A then again [19:07] type comma and finally type quote actor [19:11] close the quote colon quote dollar curly [19:14] braces and inside the curly braces we [19:17] need to write here GitHub do actor for [19:20] the username close the curly braces and [19:23] the single quote and we are done here to [19:27] make sure everything is correct um my [19:30] bad this is a steps spelling mistake and [19:34] uh node version version spelling is [19:38] this. Okay, control S for save. And now [19:40] we are all done. Now that our code is [19:43] ready and our pipeline is set, we need a [19:47] place where the self-healing magic [19:49] actually happens. For that, we are going [19:51] to use N10 which is a powerful workflow [19:55] automation tool. Let's set up our [19:58] account. First, let's head over to the [20:00] Google and simply search for N8N. You [20:04] will see the official website right at [20:06] the top, niten.io. [20:09] Let's go ahead and click on that first [20:11] link. Once you are on the homepage, look [20:14] for the sign-in button at the top right. [20:17] Now, click on start a free trial here. [20:19] Enter your professional or personal [20:21] email address here. Make sure it's an [20:24] active one because we will need to [20:26] verify it in the next step. GitHub and [20:29] niten are very secure. So check your [20:32] inbox for a verification code. Once you [20:35] verified this, it will bring you back [20:37] here to finalize the setup. Now let's [20:40] fill in the basics. Enter your full [20:42] name. Create a strong password and enter [20:46] your account name. This will be your [20:48] personal automation workplace. Now click [20:50] on start free 14-day trial. Aniten will [20:54] ask you a few questions to personalize [20:56] your experience things like your role or [20:59] what you plan to automate. Don't [21:01] overthink it. You can select any options [21:04] here that fits you best and click next. [21:07] You can also invite team members or you [21:10] can simply click on skip. Once you have [21:12] cleared the questions, click on that big [21:15] start automating button. This is where [21:18] your journey into AIdriven DevOps truly [21:21] begins. And there we go. Our account is [21:24] live now to keep things clean and [21:27] professional. We will click on start [21:29] from scratch. This gives us a blank [21:32] canvas to build our custom self-healing [21:35] workflow. First, let's fix this mistake. [21:38] The spelling of workflows is currently [21:41] incorrect. I am going to press F2 to [21:44] rename the folder and correct the [21:46] spelling to the workflows. Now, press [21:48] enter. And there we go. All right. Now [21:51] it's time to connect the dots. We need [21:53] to set up our repository and secure it [21:56] with the variables we defined in our [21:59] YAML file. First, let's head over to the [22:02] Google. Go to your GitHub account. Click [22:05] on the repositories tab and hit the new [22:07] button. I will name this repository [22:10] self-healing CI/CD pipeline using nitin. [22:14] I will leave the description blank here [22:16] because it's optional. Scroll down and [22:19] then click on create repository button. [22:22] Perfect. Our remote space is ready. Now [22:25] we need a way for any to talk back to [22:28] the GitHub to fix our code. For that we [22:31] need a PA a personal access token. Think [22:35] of this as a secure password that allows [22:38] an application to perform actions on [22:41] your behalf. Go to the your GitHub [22:43] account. Click on settings button. [22:46] Scroll down and then click on developer [22:49] settings. Select the personal access [22:51] token. We will choose tokens classic [22:54] because it gives us a specific control [22:56] over the scopes we need. Now click on [23:00] generate new token. Select generate new [23:02] token classic. I will add a note like [23:05] N8N. Now the scopes are very important. [23:10] We are selecting repo workflow admin [23:15] and admin repo hook. We need these [23:18] scopes because our AI is not just [23:20] reading code. It needs permission to [23:23] push fixes, update workflows and manage [23:26] hooks. Scroll down and hit generate [23:29] token. Copy this immediately and paste [23:32] in your notepad. GitHub will not show [23:35] this to you again. Now go back to the [23:38] repository. Click on the settings [23:40] button. Scroll down. Then click on [23:43] secrets and variables and select [23:45] actions. We need to add three secrets we [23:48] used in our YAML file. Click on new [23:52] repository secret. The first name is gh [23:56] token which means GitHub token. Paste [23:58] the personal access token we just copied [24:01] into the field and click on add secret [24:04] button. This allows our pipeline to [24:07] authenticate with GitHub. Next, create [24:10] another secret. Name this secret NAT web [24:13] hook secret. You can type any strong [24:16] string here. I will use my secret 1 2 3 [24:21] and then exclamation mark. This acts as [24:25] a digital handshake to an end knows the [24:28] request is coming from our repository [24:31] and not a random hacker. I will copy [24:34] this and save this in my notepad because [24:37] we will need it inside the nitn letter. [24:41] Now click on add secret button. Now [24:43] again click on new repository secret. [24:46] The last secret is n web hook URL. For [24:50] this we need to jump back to the nan. [24:52] Click on the plus icon and search for [24:55] the web hook node. Select this web hook [24:58] node. A web hook is basically a URL that [25:01] listens for data. When our pipeline [25:04] fails, it will send a post request to [25:06] this URL. Select the post method here [25:10] and then copy this test URL. We use the [25:14] test URL during development. So we can [25:17] see the data coming in live. Once the [25:20] project is finished, we will switch to [25:22] the production. Now paste this back into [25:25] our GitHub secret and save this. Double [25:29] check that these names DH token and at [25:32] web hook secret and at web hook URL [25:35] exactly match what you wrote in your [25:38] mainl file. Case sensitivity matters. [25:42] Now back in VS code we will create a new [25:45] file in the root directory in our [25:48] project. Name this file dot get ignore [25:51] and then press enter. We add node [25:55] modules here because we don't want to [25:58] push thousands of library files to [26:01] GitHub. The pipeline will install them [26:04] automatically. Press Ctrl S for save and [26:07] then open your VS Code terminal. Type [26:10] get init command for initialize this [26:13] folder as a local Git repository. Now [26:16] type get add dot to stage all our files [26:20] for the first commit. Now type get [26:24] commit dash m and write any message here [26:28] like I'm typing here first then press [26:31] enter. This saves our progress locally. [26:34] Now type get remote at origin and you [26:39] need to paste your GitHub repo URL here. [26:42] For that go to your GitHub account. [26:45] Scroll up then click on code section. [26:48] Copy this URL and paste it here and then [26:51] press enter. This command connect our [26:54] local folder to GitHub. Now type get [26:58] branch dash capital M and then main and [27:01] then press enter. This command rename [27:04] our default branch to main to match [27:07] GitHub's standard. Now type get push- [27:11] u origin and then main and then press [27:14] enter. This sends our code to the cloud. [27:17] Now if you refresh your page, you will [27:20] see your code is live. If you check the [27:23] actions tab, click on the details here. [27:26] The pipeline is already running. Since [27:28] our code is currently correct, the [27:31] pipeline should finish with a green [27:33] check mark. Now it's time to get put our [27:37] system to the test. We are going to [27:39] intentionally break our code and see if [27:43] nit catches the failure. First let's [27:46] back to the VS code and open the test.js [27:50] file. I'm going to find the line const [27:53] app equal to express and delete it. [27:56] Without this line, the server will not [27:58] initialize which will cause our smoke [28:02] test to fail. Let's press Ctrl S to save [28:05] this file. Now let's back to the NAN and [28:09] configure our listener. I will click on [28:12] the web hook and change the name to the [28:15] GitHub failure web hook for better [28:20] organization. Under the authentication, [28:22] I will select header O and click on [28:25] setup credential. This is important [28:27] because we don't want just anyone [28:30] triggering our workflow. I will name [28:33] this N8 n web hook [28:38] secret and then press enter. For the [28:41] secret name, I will type x dash web hook [28:46] dash secret. This must match exactly [28:50] what we wrote our main.yml file. For the [28:54] value, I will go to the my notepad. For [28:56] value, I will go back to the notepad. [28:59] Copy the secret I saved earlier and [29:02] paste it right here. Scroll down and [29:06] click on save button. Perfect. Our [29:08] security is set. In the response mode [29:11] setting, I will change it to when last [29:14] node finishes and response data equal to [29:17] no response body. This ensures nit [29:20] acknowledge the request only after [29:22] processing the logic. Now let's get back [29:25] to the VS code. Open your terminal. Then [29:29] type get add dot and press enter. This [29:33] command is stage our broken code. Next [29:36] get commit minus m and then write any [29:41] message here like changes one and then [29:44] press enter. We are committing this [29:47] deliberate error. So the pipeline has [29:49] something to react to. Before I push [29:52] this code, I will go to the nitn and [29:55] click on listen for test event. Now an [29:58] is actively waiting for a signal from [30:01] GitHub. Back to the VS code and let's [30:04] run get push command and then press [30:07] enter. Our broken code is now flying to [30:10] GitHub. If we check to the GitHub [30:13] actions, click on the code button, the [30:15] pipeline will start and as expected, [30:18] it's going to fail during the run test. [30:21] If we click on the details button, it [30:24] will immediately notify to an if we go [30:27] to the nitin, click on JSON button, you [30:31] can see the data has arrived in our web [30:34] hook. You can see the run ID, repo, [30:38] branch name, commit, actor here in the [30:41] output. Now that we have the failure [30:44] data, we need to find out why it failed. [30:48] We need the actual error logs from [30:50] GitHub. Let's close this web hook node [30:54] and click on the plus icon to add a new [30:57] step. Search for the HTTP request node. [31:01] This node is the bridge that allows any [31:04] to talk to any external API. In our [31:08] case, the GitHub API. Let's add it. [31:11] First, let's rename this node to fetch [31:15] logs and then press enter. So, our [31:18] workflow stays organized. We will keep [31:21] the method as get because we are simply [31:24] getting data from GitHub. Now, pay close [31:27] attention to the URL. We need to point [31:30] it to the specific job that https [31:34] colon/appi.github.com/repos [31:40] and then again slash. Now instead of [31:43] typing the repo name we will make it [31:45] dynamic. Go to the input data on the [31:48] left. Open the body and simply drag and [31:51] drop repo variable here. Now type / [31:55] actions slash runs slash and again drag [31:59] and drop run id here. Finally finish the [32:03] URL by typing / jobs at the end. Now [32:08] close this. What we just did is created [32:11] a dynamic link. No matter which [32:14] repository or which run fails, N10 will [32:17] always fetch the correct logs for the [32:20] specific instance. Now close this. [32:23] GitHub's API will not gives us the data [32:26] without permission. So click on [32:28] authentication. Select generic [32:30] credential type. From the list select [32:32] beer o. Now click on setup credential. I [32:36] will name this GitHub. P A means [32:40] personal means personal access token. [32:43] Now for the token we need our personal [32:46] access token. I will go back to the [32:48] notepad. Copy that long pat string we [32:52] generated earlier and paste it here. Now [32:56] click on save button. Close this. We are [32:59] ready. Now click on execute step. It [33:02] generates an error because the space of [33:04] this URL. Now again click on execute [33:07] step. Hitan will reach out to GitHub and [33:10] bring back a detailed JSON response [33:13] containing all the job details including [33:16] the status and the logs location. And [33:19] there it is. You can see the output [33:22] right here. Now that we have the logs, [33:26] we need to know exactly which files were [33:29] modified in the latest commit. This [33:32] helps the AI narrow down where the bug [33:35] is. Let's close the fetch logs node [33:38] again. Click on the plus icon. Search [33:41] for the HTTP request node and add it to [33:44] our canvas. I will rename this node to [33:48] fetch changed [33:51] files and then press enter. We are still [33:54] using the get method because we are [33:57] requesting information from GitHub's [33:59] comparison engine. Now this URL is very [34:03] very important. I'm going to type it out [34:06] and explain every single part of it. [34:10] Start with https colon double slash [34:14] api.github.com/repose/ [34:20] first we add to the repository name [34:23] dynamically. So we write here double [34:26] curly braces and then space dollar [34:29] parentheses single quotation and select [34:32] GitHub failure web hook dot first method [34:36] and then dot JSON dotbody dotrepo. This [34:41] ensures we are always looking at the [34:44] right project. Next type slash write [34:48] compare slash. Now we need to compare [34:51] the state of the code before the push to [34:54] the state after the push. To do that we [34:58] take the current commit double curly [35:00] braces again dollar sign parentheses [35:03] single quotation and then select GitHub [35:06] failure web hook. Again write dot first [35:09] method then dot JSON dot body and then [35:13] dot commit. Now I will add a tilt sign [35:17] here and the number one followed by the [35:20] three dots. This syntax tells GitHub [35:23] show me the difference between the [35:25] previous version means minus one and the [35:28] current version. Finally I will add the [35:31] current commit again. For that again [35:33] double curly braces dollar sign [35:36] parenthesis single quotation and then [35:38] select GitHub failure web hook. again [35:41] write dot first method and then dot JSON [35:45] dot body and then dot commit. This [35:49] completes the from to range. So in [35:52] simple words, this URL ask GitHub what [35:55] exactly changed in the specific commit. [35:58] This is how the AI will know that we [36:01] edited test.js and not some other files. [36:05] Now close this. Click on the [36:07] authentication. Select generic [36:10] credential type and then select again [36:12] beer o. Select GitHub P we created [36:16] earlier. Now let's hit execute step. [36:19] GitHub will analyze the commit and [36:22] return a list of files. As you can see [36:25] in the output, it clearly shows that [36:28] test.js was modified. It even gives us [36:32] the patch data which shows exactly what [36:35] lines were added or removed. Now we know [36:38] the file name is test.js but now we need [36:42] to grab the actual code inside it. Let's [36:46] fetch the raw content so our AI can [36:49] analyze the logic. Close the fetch [36:52] change files node. Click on the plus [36:54] icon. Search for the HTTP request node [36:58] and add it to your canvas. Now let's [37:01] rename this node to fetch file content [37:06] and then press enter. The reason we need [37:09] this is simple. GitHub's previous [37:12] response only gave us the patch or the [37:15] difference. To fix the whole file AI [37:18] needs the complete source code. Again we [37:21] will use get method because we are [37:24] downloading the file content from GitHub [37:26] server. Now for the URL we are going to [37:29] type a static link. We are going to use [37:32] the dynamic data from previous step. [37:35] Type this carefully. First write double [37:38] curly braces then dollar sign and then [37:41] parentheses single quotations and then [37:44] select fetch changed files. Then type [37:47] dot first method and then dot JSON dot [37:51] files. Inside the square bracket, write [37:54] zero and then dot raw underscore URL. [37:59] Let me explain what this means. Fact [38:01] change files tells any to look at the [38:04] data from our last node. Dot first [38:08] ensures we are taking the first [38:10] successful response.json [38:12] files points to the very first file that [38:16] was changed. Dot raw URL is the magic [38:19] part. It's a direct link to the plain [38:22] text version of your code bypassing the [38:25] GitHub UI. Now close this and then click [38:28] on execute step button. If you look at [38:31] the output now instead of JSON metadata, [38:35] you will see your actual JavaScript code [38:38] exactly as it sits in your VS code [38:41] including the error was created. Now we [38:45] have everything ready for the AI to take [38:48] over. Now that we have the logs, the [38:51] files and the code, we need to package [38:54] them into a single prompt for the AI. [38:57] For this, we are going to use a code [39:00] node. Let's close the fetch file content [39:03] node. Click on the plus icon. Search for [39:06] the code node and select code in [39:09] JavaScript. I will clear the default [39:12] code and paste the custom JavaScript [39:14] code from my notepad. Let me explain [39:18] what this code is doing line by line. In [39:22] the first two lines, we are capturing [39:24] the payload from our original web hook [39:27] and the JSON data from our fetch logs [39:31] node. This gives us the basic info who, [39:34] what, and where of the failure. Next, we [39:37] are filtering the jobs to find exactly [39:40] which one failed. We use the dotfind [39:43] method to look for a status called [39:46] failure. Once we find the job, we also [39:50] extract the specific failed steps so [39:53] that AI knows exactly where the process [39:56] crashed. Then we create a step details [39:58] constants. This maps out the name, [40:01] status and the timing of the failure [40:04] into a clear string. This is crucial [40:07] context for the AI to understand the [40:10] sequence of events. Now we look at the [40:13] change file since a commit can have [40:15] images or readme files. We define a list [40:19] of code extensions like JS.ts or py. We [40:25] filter the files to make sure the AI [40:27] only focus on relevant source code and [40:30] ignores anything that was deleted. Here [40:34] we handle the file content and it can [40:36] sometimes send data as a string or an [40:39] object. So this logic ensures we extract [40:42] the actual code correctly regardless of [40:45] the format. This is the code that the AI [40:48] will eventually fix. Now we build the [40:51] file sections. We use a loop to go [40:54] through our relevant files, identify [40:56] their language like mapping JS to [40:59] JavaScript and then wrap the code in [41:02] markdown back takes. This ensures the AI [41:05] reads the code in its proper syntax. [41:08] Finally, we combine everything into a [41:11] massive constant called prompt. This is [41:14] a dynamic template that includes the [41:16] repository, branch, commit, and the [41:19] specific code files that need attention. [41:22] We are also giving the AI strict [41:25] instructions to return the fix in a [41:27] valid JSON format so we can process it [41:30] automatically in the next step. Now [41:33] close this and click on execute step [41:36] button. And there you go. In the output, [41:39] you can see a perfectly structured [41:41] report. It contains all the failure [41:44] details and the source code ready to be [41:46] sent to the AI. This is how you bridge [41:49] the gap between the raw logs and the [41:52] artificial intelligence. Now our failure [41:55] report is ready. We need a brain to [41:58] analyze it. Let's bring in OpenAI to [42:01] find the bug and generate the solution. [42:04] Let's close the code node and click on [42:07] the plus icon. Search for open AI and [42:10] select the action message a model for [42:13] the resource. I will select text. Now a [42:16] quickly tip niten gives you some free [42:19] credits to start with which is great for [42:21] beginners. But if you want to use your [42:24] own API key for better control. I will [42:27] show you how to do that. Head over to [42:30] the Google search for open AI key and [42:33] click on the very first official link. [42:36] You will need to create an account and [42:38] add at least $5 to your credit balance [42:41] to activate the API. Once done, go to [42:45] the API keys. Click on create new secret [42:48] key. Name it whatever you want. Create [42:51] secret key. Then copy this and go back [42:54] to the NAN. Click on setup credential. [42:57] Paste your API key here and then click [43:00] on save. Now close this. Make sure the [43:04] operation is message a model. For the [43:07] model, we will select GPT4 mini. It is [43:11] incredibly fast, cost effective and [43:13] perfect for logical task like fixing [43:16] code. In the messages section, set the [43:19] role to the system. The reason we use [43:22] the system role is to define the [43:24] personality and rules for the AI. We are [43:27] basically telling it how to behave [43:30] throughout the conversation. I will [43:32] paste this specific prompt. You are an [43:35] expert DevOps engineer and NodeJS [43:37] developer. Analyze the provided CI/CD [43:40] failure logs and the source code. [43:42] Identify the bug and provide a complete [43:44] fix constraints written only a ro valid [43:48] JSON object. No markdown, no code [43:50] blocks, no conversational text. The [43:53] branch name must be unique and specific [43:56] to the fix like AI fixing express in it. [43:59] Do not use main or master. The fixed [44:03] code must be entire file content with [44:05] the file applied. JSON schema branch [44:08] name, file path, fix code, PR title and [44:12] PR body. Now copy this and paste it [44:15] here. Then scroll down. Now click on add [44:18] message. This time we are using user [44:21] role. The user role represents the [44:23] actual data or question we are asking. [44:26] Instead of typing, I will go to the [44:29] previous output. Drag and drop our [44:31] dynamic prompt. Now, if we click on [44:34] execute step and look at that, we have a [44:37] perfect JSON response. The AI given us a [44:40] branch name, the complete fix code, and [44:44] even a detailed pull request title and [44:46] body. It's exactly what a human [44:49] developer would do, but in seconds. Now [44:52] that the AI has provided the solution, [44:55] we need to clean that data and prepare [44:58] GitHub for a new branch. We never push [45:01] AI code directly to the main branch. [45:04] Safety and manual review always comes [45:07] first. Let's close this node. Click on [45:10] the plus icon and search for the code [45:13] node. Select code in JavaScript. Rename [45:16] this node to extract AI response and [45:21] then press enter. Now I am going to copy [45:25] this code and paste it here. Let's break [45:29] it down. We access the open AI response. [45:32] If the response is empty or formatted [45:35] incorrectly, we throw an error [45:37] immediately to prevent the workflow from [45:40] processing with bad data. This is vital. [45:43] Sometimes AI reps its answer in markdown [45:46] code fences. This line uses a regular [45:49] expression to strip those away, leaving [45:52] us with a clean JSON string. We turned [45:55] that string into a real JavaScript [45:57] object. We also verify that fix code [46:00] field exist. If the AI failed to provide [46:03] the actual fix, the process stops here. [46:07] At last, we return a clean object. [46:09] Notice that B 64 content line. GitHub's [46:14] API requires code to be sent in B 64 [46:17] format. We are converting our fix code [46:20] into that specific encoding right here. [46:23] So GitHub can read it. Now close this [46:26] and then click on execute step. As you [46:29] can see in the output, everything is now [46:32] perfectly organized. We have the branch [46:35] name, file path, fix code, base 64 [46:38] content, PR title, PR body, repo and [46:41] then commit. Now close this node and [46:44] click on the plus icon. Search for the [46:47] HTTP request and rename it to the create [46:51] space branch and then press enter. The [46:55] method must be post. We use post method [46:58] because we are creating a new resource [47:00] on GitHub server specifically a new git [47:04] reference. For the URL type https colon [47:09] double/ ai.github.com/repost/ [47:16] drag and drop the repository name here. [47:19] Make sure there is no space between [47:21] them. Now type slash and then get then [47:25] again type slash and then type refs. [47:28] This is the official endpoint for [47:30] creating branches. We are using the [47:33] dynamic repository name we captured [47:35] earlier. Now click on authentication. [47:38] Select generic credential type. Select [47:40] beer o and pick github pet. Since we are [47:44] creating a branch modifies the [47:46] repository. Your personal access token [47:48] is required. Now toggle send body to on. [47:52] Set the body content type to JSON. [47:55] Specify body using JSON. Inside the JSON [47:58] block, we will provide two key pieces of [48:01] information. First, we open and close [48:04] the curly braces. Inside the curly [48:06] braces, open and close the double [48:09] quotations. Inside the double [48:11] quotations, write ref. Then after the [48:13] quotations, type colon and then open and [48:17] close the double quotations. Inside the [48:19] double quotations, write ref / heads [48:23] slash then drag and drop our branch name [48:26] here. Now type comma and press enter. [48:30] Again, open and close the double [48:31] quotation. Inside the double quotation, [48:34] type sha then type colon and then open [48:38] and close the double quotations. Inside [48:40] the double quotation, drag and drop your [48:43] commit ID here. Ref tells GitHub the [48:47] name of our new fix branch and SHA [48:50] ensures the new branch starts from the [48:52] exact point where the failure occurred. [48:55] Now everything is fine. Click on execute [48:58] step button and boom the branch is [49:01] created. Now why did we create a [49:04] separate branch instead of fixing the [49:06] main branch directly? Security and best [49:09] practices. We never want an AI to [49:12] overwrite our production code without [49:15] human oversight. By creating a branch, [49:18] we keep the human developer in the loop [49:21] to review and approve the changes before [49:23] they go live. Our branch is ready. But [49:27] before we can push the fix code, we need [49:30] to do one very important thing. We need [49:33] to get the files SHA or unique [49:35] identifier. Let's start that up now. [49:39] Close this node. Click on the plus icon [49:42] and search for the HTTP request. Let's [49:46] rename this to get file sha and then [49:52] press enter. Keep the method as get. Now [49:55] why are we doing this? GitHub will not [49:58] let you update a file just by sending [50:01] the new code. You have to provide the [50:04] SHA which is like a digital fingerprint [50:07] of the current file. This proves you are [50:10] updating the latest version and not [50:12] overwriting someone else changes by [50:15] mistake. For the URL type https colon [50:20] double/api.github.com/repost/ [50:22] github.com/repost/ [50:26] select expression here double curly [50:29] braces dollar parentheses single [50:32] quotation and select extract AI response [50:36] then type dot item dot JSON and then [50:40] dotrepo after that type slash then type [50:44] contents then again type slash and then [50:48] double curly braces dollar parentheses [50:51] is single quotation extract AI response [50:55] dot item dot JSON dot files [50:59] path. Let's break down this. We are [51:02] telling the GitHub API go to the [51:04] specific repository. Look into the [51:07] content and find this specific file path [51:11] that the AI identified for fixing. By [51:14] hitting this URL, GitHub will send us [51:17] back the metadata of that file including [51:20] its current SHA. Now close this. Under [51:23] the authentication, select generic [51:25] credential type. Then select bearer O [51:28] and pick GitHub pet. Even though we are [51:31] just reading information because this is [51:33] a private repository, we must provide [51:36] our token. Now click on execute step and [51:40] boom, there it is. In the output, you [51:43] can see field called SHA. It's a long [51:46] string of numbers and letters. We will [51:48] need this exact string in our next step [51:51] to successfully update the code in [51:53] GitHub. Now that we have the unique SHA [51:57] of the file, we can finally push the AI [52:00] fix back to the GitHub. Let's configure [52:03] the update node. Close this node. Click [52:07] on the plus icon. Search for the HTTP [52:10] request node. Rename it to push fix file [52:16] and press enter. For the method, we are [52:18] selecting put method. We use put method [52:21] because we are not creating a new file. [52:24] We are replacing the content of an [52:27] existing one with our corrected version. [52:30] Type the following URL. https [52:33] colon/api.github.com [52:37] github.com/repose [52:40] slash click on expression double curly [52:44] braces dollar sign parentheses single [52:47] quotation and select extract AI response [52:50] then type dot item dot JSON dotreo [52:55] after that / contents/ [52:59] again double curly braces dollar [53:02] parenthesis single quotation select [53:04] extract AI response Then type dot item [53:08] dot JSON and then dot file path. This [53:12] URL targets the exact file in our [53:15] repository that needs the fix. For [53:18] authentication, select generic [53:20] credential type. Then select beer o and [53:23] pick github pet. This action requires [53:26] write permission. So our token is [53:28] essential. Toggle send body to on. [53:31] Select body content type to JSON a [53:33] specific body using fields below. We [53:36] need to add four specific parameters [53:38] here. First one is message for the [53:42] value. So drag and drop PR title here. [53:45] This serves as our commit message. Then [53:48] click on add body field. Name this [53:51] content. And for the value, drag and [53:53] drop base 64 content. Then again click [53:57] on add body. Name this SHA. Then drag [54:00] and drop SHA from the previous node [54:03] output. This tells GitHub, I know this [54:06] is the latest version now updated. Click [54:09] on add body field. Name this branch. [54:12] Drag and drop the branch name from [54:15] extract AI response. Now click on [54:17] execute step button. The fixed code is [54:20] now sitting in our new branch on GitHub. [54:24] The code is fixed but we need to notify [54:26] the team so they can merge it. The final [54:30] step to automatically opens a pull [54:32] request. So close this node. Click on [54:34] the plus icon. Search for the HTTP [54:37] request and rename it to open pull [54:41] request. So I'm writing here open pull [54:44] request and then press enter. Select the [54:47] method to the post method because we are [54:50] creating a new pull request. The URL is [54:53] https col//appi.github.com/repos/ [54:58] github.com/repose/ [55:02] click on the expression then type double [55:05] curly braces dollar sign parenthesis and [55:09] select extract AI response then type dot [55:12] item dojson dotrepo and after that / [55:18] pulls this is our official link for pull [55:21] request now click on authentication [55:23] select generic credentials type again [55:26] click on beer O and pick GitHub pet. Now [55:29] toggle send body to on. Select JSON and [55:33] using fields below. We will add these [55:35] four parameters. First one is title. [55:39] Drag and drop the PR title from extract [55:42] AI response. Then click on add body [55:44] field. Write name body. And for the [55:48] value, drag and drop the PR body from [55:50] extract AI response. Then click on add [55:53] body field. Name this head. And for the [55:56] value, drag and drop the branch name [55:59] from extract AI response. Then again [56:02] click on add body field. Name this base. [56:05] And for the value right here main. This [56:08] tells GitHub that we want to eventually [56:11] merge our fix into the main branch. [56:14] Click on the execute step button. And [56:16] there we go. If we jump over to the [56:18] GitHub, go to the pull request, you can [56:22] see our AI generated fix waiting for [56:25] review. The code changes are there and [56:27] our CI/CD has successfully healed [56:30] itself. If we click on merge pull [56:33] request, confirm merge and boom, you [56:36] successfully merge this. If we go to the [56:38] code section, you can see our pipeline [56:41] is successful. To make this truly [56:44] professional, we should not have to [56:45] check any or GitHub manually. Let's set [56:48] up an automated email notification to [56:51] the team knows exactly when a fix has [56:55] been posted. Close the pull request [56:57] node. Click the plus icon and search for [57:01] Gmail. Click on this. Search for send a [57:04] message. Click on sign in with Google. [57:08] Check this and then click on continue. [57:10] For the subject, I will type CI CD [57:15] failure. Fixed and pushed by AI. Fixed [57:19] and pushed by AI. Now write an email [57:24] address. Select text. And for the [57:27] message, I'm writing this. We are [57:30] pulling the repository name from GitHub [57:32] failure web hook. Branch name from [57:35] extract AI response. PR title from [57:38] extract AI response and JSON body repo [57:41] from GitHub failure web hook. This is [57:44] our email. Now close this and click on [57:47] execute step. Now let's jump over to my [57:50] Gmail. A realtime notification with all [57:54] the details and the link to the fix. [57:57] This is how you keep your team in the [57:59] loop without lifting a finger. If you [58:03] want to remove this attribution, you [58:05] simply go to the Gmail node. Click on [58:07] add options [58:09] then click on append nan attribution and [58:12] toggle off this. Now again if we click [58:15] on execute step go back to the Gmail [58:18] account and as you can see there is no [58:20] nitn attribution here. Right now we are [58:23] in test mode. To make this permanent [58:25] part of your workflow we need to take it [58:28] to production. Go back to the nitn close [58:31] this. Open your GitHub failure web hook [58:34] node. You will see two tabs. Test URL [58:38] and production URL. Click on production [58:40] URL and copy this. This URL is permanent [58:44] and will always be listening for [58:47] failures. Now close this and click on [58:50] this publish. Click on publish. Now [58:53] click on go. Got it. Your workflow is [58:56] now live and running in the background. [58:58] The final step to tell GitHub to use [59:01] this new URL. Go to your GitHub [59:04] repository. Then go to settings. Scroll [59:07] down and then click on secrets and [59:09] variables. Select actions. Now go to [59:12] your GitHub web hook URL. Click on this [59:16] pencil icon and for the value paste the [59:19] updated URL here. This is your [59:21] production URL. Now click on update [59:25] secret. And that's it. You have built a [59:27] fully autonomous AI powered self-filling [59:31] CI/CD pipeline. From detecting a failure [59:34] to analyzing logs, writing code, and [59:37] notify the team, everything is now [59:40] automated. This project shows that AI is [59:44] not here to replace developers. It's [59:46] here to empower them. You can now spend [59:49] less time to debugging simple errors, [59:52] more time building great features. If [59:54] you followed along and build this, share [59:57] your results in the comments.