Manually Connect a Keystatic Project To A GitHub Repo

[00:00] If you still want to connect your project with GitHub but do it manually, you can use the GitHub mode in key static. In the admin UI, I will change the storage kind from cloud to GitHub, which is one of the 3 options. And you see that TypeScript is telling me, hey, something's wrong. When you set the storage modes to GitHub, you also need to have a repo property. [00:20] Alright? So be it. So, repo. And the repo can either be an object with the owner and name property. So, in our case, the owner is correct but the name is egg head key static next JS blog. And I don't think it matters but let me comment out the Cloud property. And if you want, you can [00:40] also pass your repo as a string which is the org or username slash the repo name, like so. Both will be valid. So there's a bit of manual setup to get the GitHub mode working. We're not going to commit these changes directly. We first need to run the project locally to trigger some setup flow. So I'll start the server, npm [01:00] run dev, and visit the local host version of my site. The first time I go to the key static admin UI, it's going to prompt me to authenticate with GitHub. And so let's do this. And here you see that if you've already created the GitHub app, which we have when setting up KeyStatic Cloud, you need to add some [01:19] environment variables in your project. And alternatively, you can go through the flow of creating a GitHub app, which is similar to what we've done for Keystudy Cloud. Here, I'll pretend I have not created a GitHub app before and will create a new one for the deploy app URL. I can paste the deployed app on Vercel and the GitHub org is Simon Swiss. [01:40] Alright. So let's create a GitHub app. I'll call this 1 key static 101. And like you've seen before, it's going to ask me to authorize this app. So the app creation was successful, and now I need to go and install it for my Simon Swiss org. And then once again, I'll only [01:59] allow the egghead key static next JS blog project and authorize. So now it will take me back to the key static admin UI and this time I'm logged in with the GitHub mode. There is my GitHub repo with the 2 branches and I can create a new branch, [02:19] GitHub mode. And for this one, let's create a new author. Let's call this author Gina. We won't add avatar or showcase, but what we'll do is go in the post and edit the post we deployed from Keystudy Cloud and add Gina [02:39] here to the list of authors. So I'll save that. And now on my dashboard, you can see that there are changes flagged for both authors and post, and I can create a pull request. This is going to take me to the GitHub repo one more time, and you can see the changes, a new author JSON file for Gina, and then Gina is [02:59] listed in the array of authors for that post. So I'll create the pull request, and something I forgot to show last time, you can see Vercel is deploying the branch preview and, oh, it just finished deploying. And so before we merge the pull request, we can visit the branch preview for this specific branch. You can see the Vercel [03:19] UI for branch previews. And so here, if I visit the 3rd post, I should see Gina added to the authors and Gina should have her own page, which is arguably a little bare bones. So behind the scenes, when we created the GitHub app, a dotenv file was generated with the necessary [03:38] environment variables for key static to work in GitHub mode. If I look in my local file system here, in authors, there is no Jina file because the changes were not made locally, like local mode, but directly on GitHub. So let me quickly merge that pull request that adds Gina as an author. And so here [03:58] I am on the main branch. And so if I git pull from that branch, we have now pulled these new content changes from the repo. And so now inside my content folder and authors, I also have Gina. Alright. So we set up locally, but now we need to make our deployed Vercel instance aware and enabled [04:18] for this GitHub mode. Before I do, we do not want to commit our dot env. This is a local thing we're gonna copy over. So in the git ignore file, I will add dot env. And so now I will commit the changes that changed the mode to GitHub. Make sure the dotenv file is not part of your changes. [04:39] And let's push that. That's going to trigger another build in Vercel and oops, you can see we have an error. What's going on? So if we check the logs, you can see that we're missing required config and it's telling us to copy the environment variables. And that's actually exactly what we should expect. And [04:59] so like I said, we did not commit the dotenv file to GitHub, but in Vercel, in settings and environment variables, we will copy and paste our values from the dotenv file created locally. So this is great UX by Vercel. You can copy the entire dotenv file and paste it all in [05:18] the first field and it's going to create the individual key value pairs as needed. I'll save this. The variables have been added successfully. And so I need to go back to deployments and we're going to trigger a new build. So redeploy. And hopefully this time, because of [05:38] the environment variables in place, the build will succeed. Alright. Nice. The deployment has completed. You can see we have Gina as a new static HTML page. And let's go visit the production site and verify that we also have Gina as an author and the page works. Perfect. And let's visit the key [05:58] static admin UI in production. This is the first time I visited on the deployed site. So again, I have to log in with GitHub. You won't have to do this after the first time. And here we are in GitHub mode in production. So this time, I will do changes directly to main. I'll create a new post called YOLO [06:18] from prod, shipping to prod from deployed GitHub mode. No authors. Let's create this. If I go to the GitHub repo, you can see that this commit has been done to main. If you want to avoid this risky behavior, you can enable branch [06:37] protection, which I don't have here for this demo. And the build has succeeded. You can see that the status is ready with this yellow from prod. So let's visit our live site, and you can see our new post yellow from prod. Oh, yeah.