🎞️ Videos → Make Pull Requests Great Again with Background Jobs using Trigger.dev NodeJS SDK

Introduction: Pull Request Challenges and Automated Solutions0:00

Okay.

Good evening. I hope you can see this. Let's start with the question. We're going to talk about pull requests. I think you all like pull requests, right? Your favorite topic. Let's find out a bit. How is it going for you and your teams with pull requests? I want to find out.

Ideal vs. Reality: Pull Request Statistics and Common Problems0:27

So there's like a guideline in general how you should do pull requests and what is a good statistic. And it says review time should be less than one hour.

Is that the case for you? Anybody? You normally take less than one hour to review a pull request?

Building a GitHub App to Automate Pull Request Reviews0:44

Huh. You take longer than one hour? Look. Not sure? Okay.

Um, No problem. Then let's try another question. How often do you review pull requests? Anybody, every day? Any one of you review pull requests every day?

Okay. Not so many. All right. I think if you've worked with pull requests before and like a pull request method and process, you will often run into issues.

Tools for Building the App: Trigger.dev, E2B, and JavaScript1:21

And as an engineer, normally we want to solve this with tooling. So what we're going to do, well, let's fix it, okay? So what we're going to do today, in this talk, the goal is going to be to understand general pull request problems. That's the first one. The second one is going to be we're going to build a GitHub app, okay? And the next one is, I want to introduce you to some tools, maybe something that would be useful for you. We're going to use Trigger.dev, the Node.js SDK. And I also want to introduce you to E2B, maybe also an interesting tool for you, okay? And of course, we're going to use JavaScript. We're in Bangkok JS, right? So, we're going to use JavaScript.

Project Overview: ‘Making Pull Requests Great Again’2:04

So, let's get started. My talk, "Making Pull Requests Great Again" using background jobs with Trigger.dev and E2B, okay? That's the goal. And quick introduction, my name is Tobias. I'm co-founder at Hubql. And we experiment with dev tooling, we do documentation tooling, and, yeah, I like memes, so I'm going to have a lot of memes. And, yeah, I like computers for a long time. That time I still had hair.

Pull Request Theory and Best Practices2:35

So let's start with theory. Talk a bit about pull requests in general. There's a guideline for how big a pull request should be. Probably, you've seen pull requests that are like very small, one-line change. Sometimes you get a pull request that is very large. And normally, it will lead to problems if the pull request is too small or too big, or if they take too long, or they're unnecessary if you have a lot of CI jobs running, for example. So it should be somewhere in the middle. That is the theory.

And also, pull request delays slow down teams. Sometimes you are waiting for tests. We just saw it with automation tests, right? They can take quite a long time to run. And so if you open a lot of pull requests, it may also lead to problems, waiting time, slow you down as a team.

The Reality of Pull Requests: Fear, Bugs, and Self-Approval3:26

But let's look at the reality. Okay, let's forget about the theory. Let's look at some actual problems with pull requests. Okay, maybe you're a junior engineer. You might be scared of the review of a senior engineer, right? What the feedback might be for your pull request. So that's daunting.

Another one as well, you might be scared if somebody finds a bug, right? That's scary, too. We don't want that to happen. And of course, general line, 10 lines of code. You will get 10 issues as feedback.

But a big pull request looks fine to me, right? Nobody is going to review all this. So that's the reality with pull requests, and the best one, you open a pull request and you approve. Right? You approve yourself.

That's the best one.

Building an Auto-Approval Agent: GitHub App Development4:26

Okay. So, since we like this one, it looks good to me, let's build an agent. Not exactly an agent, but we're going to try. Let's build one. So who has built a GitHub app before? Any one of you? Have you built one? No. Okay, cool. Let's build one. So, when you do a GitHub app, first thing you're going to notice, you have to use the GitHub API, and you're going to have a problem with rate limiting. The GitHub API is normally quite limited to a certain number of requests you can do. So that's a problem you're going to run into.

Handling Webhooks and Rate Limiting with Elysia and Trigger.dev5:04

And you have to handle webhooks. Webhooks are also something that may be annoying for you. If you've worked with webhooks before, you will know you're running into issues. Something that's maybe a bit more challenging than other kinds of implementation. So what we're going to do This is going to be our GitHub app. Okay, first one. If you have a GitHub app, you have to subscribe to an event. So you receive a GitHub event, and in this case, it's going to be when the pull request is opened. Of course, same as the previous talk, we like Elysia. Right, so we're going to use Elysia as our API handler. And then we're going to use Trigger.dev. Trigger.dev is going to handle the background job, something that runs after we receive the webhook. And then we can forward this to run an agent, agent-based, on the changes that we have and perform some changes. I'm going to run this in E2B, a sandbox, so like a small server that runs for you. And then we send the data back to GitHub.

Subscribing to GitHub Events and Triggering Background Jobs6:06

Okay, first one. If you look at GitHub, if you build an app, you can subscribe to events. One of the events is called pull_request.opened. So whenever somebody opens a pull request and you have the app installed, you're going to receive the event. You can also subscribe with the GitHub action, for example. Now, next step.

We're going to use Elysia to receive the webhook. Okay? This is going to be a POST endpoint. We're going to validate the webhook, and trigger a task to trigger.dev.

How does that look? I hope you can see this. So, basic Elysia app, a POST endpoint. And then what we can do, I skipped the part of validating the webhook, okay? You should verify normally if you receive the webhook. And then we do a switch and we check what kind of event is it? In our case, we look at opened and also reopened. And then as a next step, we are going to use task trigger. Task trigger is basically we're going to invoke a background job using the trigger.dev SDK. I have a repository and you can take a look later. So, I'll just go over the concepts a little bit for you.

Using Trigger.dev for Background Job Management7:26

Next one, trigger.dev. What are we going to do? Okay. Why do we use trigger.dev? Well, they have open source JavaScript SDK. They're open source, you can self-host. So I like that. Let's use trigger.dev, but you can use something else as well. They claim themselves as a open source background jobs platform. So what they offer is different things. workflows, agents that you can run. You can control concurrency, you can do queues, retries, all the things that you normally need if you have a system that needs to be a bit more reliable.

Okay, how does that look? You can define all the task and background jobs in code. Okay. So let's say you receive an event, you're going to invoke a certain task. You can do this by ID, and then you forward the payload of a webhook. Okay, that's an example here.

Implementing Business Logic: Four Key Steps8:25

And now what do we have to do? Well, we need a little bit of business logic, right? Now that we have the event that we have received, what is the next step? We have to do four steps. Okay? We will go through each one of them, one by one.

Step 1: Retrieving Data from GitHub with Octokit8:40

So, first one. Getting the data from GitHub, okay? Imagine you receive a webhook as an event. What do you want to do if you have a GitHub app? Normally, somebody installed this, right? And then you get an installation ID. Installation ID

You can assign a token and use this as acting as the GitHub app. Okay. That's the authentication and authorization part that you can do. And once you have this, you can use Octokit. Okay? Octokit is an SDK that you can use, Node.js

based, and you can interact with the GitHub API. Okay, we are going to use Octokit. And the next step is going to be

Step 2: Utilizing Agents with E2B Sandbox9:28

agents. Okay, what are we going to do with agents? Let me introduce you to E2B. First of all, E2B, their goal is to produce sandboxes where you can run agent-generated code, okay? Or AI-generated code. This can be unsafe to do. Right? So you might want to have a sandbox, something standalone, that's not running in your infrastructure, but maybe in another place. has a sandbox, so you can use E2B. and they also have an SDK for Node.js, so we're going to use that. Then you can use it. This might be a little too small. But what you can do is sandbox.create

and then you can interact with the sandbox sending shell commands, for example. So what you can do is any command that you can think of, if you run like an Ubuntu machine, for example, right? So you can send commands, but you can also produce new files, you can use files, you can generate code in there and then get it back. So it's like a sandbox environment where you can do testing or other things that you want to do in this sandbox.

Okay. How to spin it up? Well, it's more or less two lines. Sandbox.create and then you can say shell.commands.run and then you can pass in the command. In our case, since we want to interact with GitHub, we're going to use Git commands, right? So what you do is Git config, Git clone and then you can run it. So maybe have something like pnpm dev, for example. You can run it and then interact with this sandbox to make changes to your cloned repository. And of course, you can use anything else to do this, but this is like a short-lived sandbox, might be useful if you just want to do some small changes.

Step 3: Running Agents with Instructions and AI Integration11:26

Now, running agents, normally this is like a combination, right? You have to do some instructions. So if you've worked with AI before, you have a prompt. This is one example. I used the example from, it's called Maige. Maige is I would say a copy of Devin, maybe. So it's something that you can use to automate some of your coding tasks. It's an engineer agent. It works as a software engineer, and it can do things for you. It can do things like testing, it can do things like doing code changes, generate documentation. So some lower-level tasks where you can use AI to generate this. The

Step 4: Sending Feedback Back to GitHub12:11

Okay, last step. Cool. Now that we have feedback from our agent, the last step is to send it back to GitHub. This is one example: create a comment. Right, your GitHub app can make a comment. But of course, it can do anything else. So if you have access to the source code, you could make changes to the source code. So what you could do is change some of the files and make a new pull request, or make a new commit, or act for you on your behalf, like fixing a bug if somebody, some of your colleagues, for example, has feedback that something has to be changed. It can be automated in this way, and they can act on your behalf.

Okay. And this is the result. Looks good to me. And it's working. You can try it. If you want, it's open source. You can clone it and use it for yourself and extend it. And yeah, it would look like this, right? If you ever had a GitHub app installed, what they're going to do is create a comment on behalf of the GitHub app.

Alternative Solutions: Ingest, Temporal, Supabase, and More13:20

Now, I want to give you some alternative solutions because this is just one example. trigger.dev to understand maybe what it does. It's similar to Ingest, maybe Temporal, if you used that before. You can use Supabase, AWS EventBridge, or you can use GitHub Actions, right? If you just want to run something on behalf of your code changes when you do a pull request. And the second one, E2B, you can use GitHub actions, for example, as well. You can, you know, just run shell commands if you want inside GitHub actions. You can use EC2 or Jenkins. Why do we use E2B?

Because they abstract away a lot of the handling of the machines and it's short-lived and it's like standalone, so it doesn't run into other issues that you may have during this approach.

Future Work: Concurrency, Retries, and Order of Execution14:13

Future work. Okay. Now, this is just a concept, right, just to give you some ideas today. I think what was missing is looking into concurrency, looking into retries is something that you have to consider when you work with webhooks. Maybe also

order of execution, right? You might have two events almost at the same time, but you don't handle them within the right order. And this is also something you can control with a system like trigger.dev. And, of course, looks good to me, maybe not enough. So, let's imagine something that might be more useful. Handling a pull request, right? You can think of ideas how you can make in your team make a small GitHub app that helps you to have something useful out of this. But in general, I want you to maybe think about how to make PRs better. Yeah, how can you maybe leverage AI within your team to reduce some of the work that is annoying for you and focus on things that are maybe more fun for you. So use that.

Call to Action: Building Your Own GitHub App and Improving PRs15:17

Okay.

Maybe you want to build something on top of this. I already gave you the framework as a whole. So feel free to scan this. Again, this is not a payment code, this goes to the repository. I'll share the link later as well. And also, if you do one of those, we might have a job for you at Hubql. So that might be some motivation for you to do it. So take a look at the repository. And if any of you are using Cursor as an IDE, please talk to me afterwards. It'll be great to have a discussion. And yeah, any questions?

Please go ahead if you have a question.

I think we still have time.

Live Demo and Q&A: Exploring the Repository Code16:19

Otherwise, in the meantime, I can go around a bit. You can go at this repository. Yeah, you can show around a bit more. Yeah, it's actually quite simple. There are only two files, one of which we saw before. One of them is the Elysia app. So this is receiving our webhook. And then what we do is task trigger. So task trigger is the trigger.dev. Let me make this even bigger, maybe. So task trigger is going to our task, pull request opened.

And then once we go back, actually can just open this.

Okay. And this is our task.

In our task, we can define some configuration. So how long we're going to run, timeout, retries. And then this is what we saw, we can get the installation ID, so we know who is running this GitHub app. And then what we can do is interact with the GitHub API using Octokit. In Octokit, you can do anything with the GitHub API, creating comments, opening issues, in this case, we just send 'looks good to me' as a comment. But you can think of anything else. And I prepared for you, if you want to go further, I made an example how to run an agent, okay? On behalf of this. What you would have to do is to, well, get the changes or just clone it.

Clone the repository and then, well, you have to do some setup in terms of, like, the tools that you want to use for your agent. And as a next step, you can then use the E2B to run your commands and interact with the sandbox. And, yeah, you might get feedback, right, from AI. AI feedback, you can forward it back to the pull request result. Can work on behalf of you. If you want to make your life easier. Yeah, this is just a starting point for you. I don't know. Any questions? Ah.

Then I think that's it. Thank you very much. See you.