Build Self-Healing CI/CD Pipelines with GitHub Copilot SDK

Hi there. So, productionizing AI agents can particularly be challenging because there's so many moving parts in an agendic system. All the way from the execution loop, memory, prompts, tools, and of course, not to forget the security. You don't want a random user to just invoke a tool call that could potentially destroy your entire database. So, in order to address all of these challenges, the GitHub team recently announced the GitHub Copilot SDK. And the core idea is that it's not this API wrapper, but rather it's a fully programmable SDK that is powered by the same copilot agent code that also powers the GitHub copilot CLI. So this gives you programmatic access for the same production tested execution loop that also powers the GitHub copilot CLI. What that essentially means is for example, if you talk about a standard agentic tool which has a planning mode, then it will be able to use different tools and it will have a proper runtime. All of these are also now being given to you with the G co-pilot SDK and you can embed them into any type of application and build based on your use case. This also means that you get all of the powerful features that are natively present within Copilot CLI including the ability to choose between different types of models all the way from Opus 4.5 to GPT 5.2. You can get the ability to define custom tools and you can also connect MCP servers right with the programmable SDK. Now at its core it works on the JSON RPC which means it's compatible with any programming language. By default GitHub has launched support for NodeJS, Python, Golang and Net. But that means you can also write your own SDKs on top of the core GitHub copilot SDK. So here is an example on how to get started. So of course we'll explore the GitHub repository but this is a short code snippet inside of TypeScript SDK. So here we first import our package. Then we initialize a new client for our copilot and use the start method to begin the execution and we create a session. So during the session all of the different requests and responses will be actually captured like any session that you might run with another uh tool for example clot code or Gemini CLI. So all of the conversations will be persisted inside of that session. So in this case we are choosing the model as GPT5 and in order to get a response we just do session send so that we can get a response based on the input prompt that we have given. So that's really it right if you take a look at this quick video where earlier we used to have um this copilot CLI so of course this would be the CLI experience but now you can go ahead and embed that by just doing an install of the relevant SDK. So in this case it's TypeScript or JavaScript. And now you can start to actually write full-fledged applications. Whether you're building a CLI, you're building a SAS application, you're building like a YouTube chapter generator, anything you want to build, you can get access to the entire aentic loop with access to all of the different capabilities that we described throughout this entire video. So now let's explore the GitHub repository for the project. Initially you'll find the installation details for all of the different SDKs. And first let's go through the getting started guide. So some of the prerequisites include in installing the GitHub copilot CLI and also just verifying that it works and ensure that you have a copilot pro subscription so that you can use the premium model. Now to get started we have these four instructions. We first go ahead and install the Python SDK. You can do it for any other language as well. So we'll just copy this command and we'll go to our terminal and we'll run this. Now while that is running we'll also take a look at our first code snippet. So we already saw this at the beginning in the blog but if you look at the Python version as well we just importing the copilot client and we are creating a session and we'll now wait to get the response for this particular prompt. So I'll just copy this particular code block and we'll create a new file and we'll do vim main.py and insert this code block. Now in order to run this we just do python main.py and we'll just wait for a second. In this case, we are going to use the GBD 4.1 model, but you can choose whatever. And of course, you can always change whatever prompt that you wish to give here. So, we get the response 2 plus 2 is 4. So, this is a very simple example demonstrating that you've trained this new session and you're getting the response. But now, what if you want to have streaming? So, you can very easily also stream the responses. So here if you take a look at the Python example once we create the session and we now want to listen to the response chunks. So of course the entire response will not come as one blob but it'll come in chunks and we'll stream these chunks. So that is also supported. Now if you want to also add a custom tool it's very straightforward. If you want to create a new tool just use this particular function called as define tool inside of Python. So in this case it's a decorator and we define the description and the actual function itself. And then when you create your client in this you also pass the tools with the specific tools that you have described yourself and you also enable streaming as true and you also provide the specific model. Now if you want to also add MCPS that's also pretty straightforward. So in order to connect to an MCP server just use this particular function uh similarly as we have done before with the create session but in this case we'll also add one more parameter which is the MCP server and the list of all the MCP servers. So in this case the example is of the GitHub and the example that I have built I've been using two different MCP servers which we'll just explore and if you want to create your own custom agents that have a specialized persona something that you want to be not natively supported from the G coil SDK you can also do that where you can give it a proper system description of what it should do and so essentially this is the system prompt for your custom agent and you can also customize the system message for all the different agents. that will be running. So you get this full-fledged capability to connect to MCP servers also of course create your own or define your own tools and stream the responses. So all of these are natively built into the copilot SDK as well. So now let's take a look at the GitHub copilot SDK in action with an actual demo. So what I've built is an AI powered SR agent that automatically monitors your GitHub actions and the workflows that are running inside of GitHub actions. It will analyze failures and take remediation action by the and the third it's using the GitHub copilot SDK to create an intelligent agent that directly interacts with your GitHub repository. So first let's explore the actual code and then we'll look at the demo. So the entire workflow is pretty straightforward as mentioned that first the G action workflow if it fails we are connecting it to a web hook request that is connected to the GitHub repository. That web hook request emits an event that is being actively listened by our server and as soon as we receive that request, we initialize the agent and the agent starts its processing. It will first uh parse and validate the payload with zod and then it will be able to analyze the workflow to see okay what is the issue and it will be able to take the appropriate action whether it's to create an issue it's to create a fix for the actual failure like whatever is the reason for the failure it will first identify that and automatically take an appropriate action to fix that. So let's take a look at our entire code. So here we have the agent of course this is written in TypeScript. So we are importing the TypeScript SDK and we are initializing our copilot client over here. Now we have defined a few tools. So these are all of the different tools. So of course we can use define tool function to create our own custom tools. So the first tool is to check the GitHub status. So in this case we are checking the status for any outage. So as soon as we get a workflow G action workflow that has actually failed, we'll be able to send that information with the help of with the help of the web hook and it'll be analyzed over here. Next, we also have a tool for managing nodes. So, this is essentially for the agent to automatically analyze why the workflow failed and take some notes so that it can take the next action whether it's to create an issue, whether it's to create a PR as well if it can actually fix or actively fix that issue that is causing the workflow to fail. So, we have uh this being managed with the Zord parameters and then we have the actual function uh the action to actually take care of uh taking the notes. Then we also have a function to to track the workflow. So the idea behind this is that in case uh the agent finds that the workflow is failing right now, it will create the GitHub issue for it and later if the issue is actually resolved or the workflow is resolved, then it will automatically be able to close that issue as well. So you don't have to manually do that. And it can automatically also create PR. So for that we have a separate tool. if it's it has a capability to create the PR and actually fix the issue it will do that as well. So these are all of the different tools that we have defined. Now if we go down uh here this is where we are actually initializing our agent uh with the start function and then this is where we can actually stop. So we have the stop function as well. So the handle workflow run initializes as soon as the GitHub repository finds that yes there is an action that is actually failing. So that workflow is failing that will automatically kick this off and this is where we'll now initialize our copilot agent and here you'll also find that we have connected it to two separate MCT servers. The first one is GitHub to be able to interact with our GitHub repository and we also have another MCP server with XA. So XAR enables real-time web searchs. So as the agent is analyzing why the workflow has failed, you can also use real world web searchs to identify the cause and find relevant resources online that can lead to better fixing that issue and create a more detailed guide on why that particular issue actually failed. And this is where now we're officially creating our session. So we'll pass the model, we'll also pass our MCP servers and all the different tools that we have created. And finally uh we initialize our session and get our responses. So we send the prompt and get all the different final responses. And this is our system prompt or the system message to our entire agent to do exactly what I've just described. So in order to basically accomplish this uh I have this GitHub uh agent YAML file that will actually invoke. So here we have given the custom instructions on this is the repository to test our S sur agent and we have also given it some specific actions. So for example it can create an issue. It can retry to run that workflow in case if it if it feels that there's a possibility to fix it on the next retry. So all of these are given here to uh manage our agent so that it can take the appropriate action. So what we'll do is we will simulate a bad workflow. So I have this YAML file that does a realtime failure test. So what we are doing here is that we are intentionally missing the npm install command when trying to do the checkout step to run our unit test. So this kind of describes a common world CI mistake. So I'll just go ahead and take this entire code and what we'll do is we'll go to our GitHub repository. I'll go to the workflow section here and create a new file. So I'll just add a new file inside of workflows. So do workflows and then I'll define fail.yamel and here I'll go ahead and paste the content to simulate this real world failure test and I'll go ahead and commit these things. So now having created our failed YAML we'll go ahead and run our server which will also initialize our entire agent. So in this case what we'll do is that now we will go ahead and make a small change a tweak in our YAML and just call this as npm command. We'll just make a small change in order to now invoke our action. So if we go to the GitHub actions here you'll see that now it has kic kicked this off. Now if you take and carefully examine our agent here you can see that this is our GitHub S agent and it what it does is that once the agent server has started it has received this web hook request which it has successfully run. So of course our as soon as the workflow actually fails the GitHub sends a post request to the web hook u event and then we pass and validate the payload with the help of zord. So now the agent has kicked off. It's now processing this workflow run event and it's analyzing what's going on. So in this case it will now start to actually use the tool. So first tool that it was to use the check GitHub status to take a look at whether the workflow has failed. Why is that failed? It will be able to fetch all of those details. And the next tool that it is called is the manage nodes. So it'll make notes about this. And you'll see that now it's uh using all of these different tools to do like web f to find some real world information by the help of the XAR MCP server to do uh realtime analysis okay if there is any fixes available on the web and it will articulate all of that into its final note and you can see that systematically it is taking care of choosing what particular tools to call and it's running all these different workflows because you can see that this particular um GitHub action workflow run actually failed and it's proactively choosing which particular tool to call. Here you can see that it automatically found out that the workflow issue is that it's operational and this workflow is mainly due to the missing npm install step before running the actual test. So it actually went ahead and created our issue. Here you can see that it actually created this live issue. You can see that proactively it gave me an entire technical investigation summary and how we can actually resolve these uh in order to get started. Now you could also transform this into a full-fledged CI/CD pipeline as well if you're running this on any type of cloud provider not just with GitHub action but you can couple it with any type of DevOps tool and you can let the agent actually take care of handling these type of reactions. So this is of course a very simple and straightforward example of automatically analyzing your PR runs or your action runs and finding out what is an appropriate action to take. In this case, I'm of course running this with my own GitHub repository. But you can very easily now change it for a GitHub access token or if you're using any type of cloud provider. You can use the relevant cloud and you can very easily change this and make it a much more well-versed um S sur agent that is still being powered and the brains behind the entire agent execution loop. Everything is being handled by GitHub copilot and I didn't have to write the logic for all that. So and that's the beauty behind this entire GitHub copilot SDK because all of the tool management tool orchestration what tool to be called after retries everything is being handled directly with the help of the copilot SDK and we don't have to write any logic for that. So that's it for this demo. If you liked this video definitely give it a thumbs up and subscribe. We'll have a lot more content around AI coming very soon. Thanks so much.