Create a GitHub Action Configuration to Automatic Deploy an Astro Blog

Man 1: [0:00] To replicate the developer experience we had with Vercel's auto deployment feature, we need to create our own GitHub actions.

[0:07] To do that, let's create a .github directory at the root of our project, and then another workflows directory inside of it. This is where all of our GitHub actions will be defined. Let's begin by creating a new file into the workflows directory and name it fly.yml, which stands for YAML.

[0:26] This is a YAML file, the format in which GitHub actions are defined. First, we're going to give it a name and we'll set it to fly deploy.Then we want to define when this action is going to get executed. It will be on push and then branches. Let's set the branch to main.

[0:46] As we mentioned, these three lines define the trigger for this workflow. When we push on the main branch, the jobs that we're going to define will be executed. Additionally, if we want to manually trigger running this workflow, we can add the workflow dispatch field. We're not going to provide a value, we just need to provide the field.

[1:08] Looking at this, we have two triggers. One is the push, which happens when we push codes to our repo, and one is the workflow dispatch, meaning GitHub is going to give us a button that we can click in order to manually dispatch the workflow. Great.

[1:24] Let's define the jobs now. Let's start by defining the jobs property and let's name our job deploy. We'll give it a name, deploy blog. We're going to give it a runs on property and have it run on Ubuntu-latest. This defines the type of machine that we want our workflow to run on. It's usually the Ubuntu-latest.

[1:47] Then we want to define the steps, which is going to be an array. The first step that we want to do is check out the repo using Git. We're starting off with a GitHub action that doesn't even have our code checked out. So that's the first thing that we want to do. Think of this as running your blog on your brand new laptop.

[2:09] You have all the necessary software for running the code, but you don't necessarily have the code. First thing you do is check out the repo using Git. Then we're going to provide the users property and set it to actions/checkout at V3. This is a predefined GitHub action. Our workflow for the first step is going to trigger a predefined GitHub action. This is how we check out the repo.

[2:36] The next action that we want to do is set up node. Set up node 18. Of course, there's already an action for that. The name is actions/setup-node at V3. Just like the last one, this is also a predefined action.

[2:54] This one also accepts a few parameters, and we can provide them with the with property. The first one we want to provide is the node- version, and we want to set it to 18. Then the second one is cache. And we want to set that to a string npm. This is going to cache all of the npm dependencies.

[3:15] The next time we run the workflow, it will already have them installed. It's going to be much faster. OK, that's it for this step. The next thing we want to do is set up the flyctlcommand. We'll provide a name, set up flyctl. We're going to provide superfly/flyctl-actions/setup-flyctl at master.

[3:42] You guessed it, this also is a predefined action. In this case, it's defined by fly.io themselves, whereas the setup node and the checkout repo were defined by GitHub. At the end, since we have the code, we have the node.js installed, we have flyctl. The last thing that we want to do is run the deploy script.

[4:04] Since that is our own npm script, this step is going to use the run property to define the CLI command that we want to run. That would be flyctl deploy.

[4:16] Then we're going to add --remote only. This command is going to start building the Docker file of our blog, which itself will trigger the npm run build command to build our whole blog site. At the end, the flyctl command will deploy our fresh Docker image to our fly.io account.

[4:36] In order to authorize the flyctl command to deploy to our account, we need to pass the fly token to this step. Aside from the run, we're going to define an env field, which stands for environment variables. Then we can define the fly_API_token. We're going to set that to dollar sign and a pair of curly brackets and inside pass secrets.fly_API_token.

[5:00] OK. Let's stop here for a second. When GitHub runs our action, it also has the opportunity to pass any environment variables that we define within our repository. Since every step triggers its own set of commands, we need to define environment variables that will get passed to each of the steps.

[5:23] In our case, the flyctl command needs the fly API token. So it knows whose image is building and where to upload it. The syntax here, dollar sign and a pair of curly brackets defines a placeholder, which GitHub is going to use to put whatever is defined as the fly underscore API underscore token. We also indicate that is going to be in the repository secrets.

[5:50] And since this is a new repository, we need to define it. Let's do that now. OK, we are at our repository. To define the fly API token as a secret, we need to open the settings of the repository, expand the secrets and variables field and click on the actions. In here, we define all of the secrets that our GitHub actions will have access to.

[6:11] To define a new one, we'll just click on the new repository secret button, we'll give it a name. So let's fly underscore API underscore token, just like we defined it in the yaml file, and then we can pass our token. To obtain the token, we need to open the fly dot IO dashboard, go to the account and click on the access tokens.

[6:31] In here, we can give it our name, Astro underscore block or whatever makes the most sense to you. And then hit create. This is going to give us that token that we're after. So we can go back and paste it into the secret field. And now we can click add secret. And there we go. That's how we add a repository secrets, and we're done.

[6:48] Now, every time we push or merge appear into the main branch, this action will get triggered and it will deploy the latest changes to our website to show you how the action is going to look like. I'm going to switch to my other repository here. If we click on the actions tab at the top, we're going to see all of our workflows.

[7:07] After you've pushed the main or merged appear to the main branch, the workflow is going to run and you'll see it here. And if we open the latest workflow and click on the deploy blog job right here, we're going to see all of the steps that we defined. The first step is automatic. Then we have our checkout repo using it where we ran the actions checkout at V3 action.

[7:30] Then our setup node 18 step ran again with the same action that we defined. Then we ran the setup fly CTL action, which was an official action by fly themselves. And at the end, we ran the run deploy script, which executed fly CTL deploy dash dash remote only on the screen. We can see all of the messages that got logged during the execution of this step.

[7:54] If our job fails or we have a bug, we'll be able to see what's going on through the logs. Again, this workflow is going to run every time we merge to main and it's going to deploy the latest changes to our production website. And that's how we can replicate versus sales out of deployment feature. Now let's do a recap with GitHub actions.

[8:13] We can define specific jobs and steps that we like to run when a certain event happens within our repository, like a push event, for example, or a manual trigger. In this lesson, we learned how to leverage GitHub actions to build our own auto deployment feature just like ourselves to define our action. We created a YAML file at the dot GitHub slash workflows directory.

[8:35] We gave it a name, define the trigger and define the steps we wanted to execute. Our action checked out the repo set up node 18 and the fly CTL command built a fresh Docker image and deployed it to our flight. I account every time we push to main or merge a PR into our main branch. Here's a bonus tip.

[8:56] If you'd also like to define a preview deployment for every PR before it gets merged, fly dot IO has already created a different action for that. To use this action, duplicate the fly dot YAML file in your GitHub workflows directory, change its trigger to pull requests instead of push and use the super fly slash fly PR review apps action in place of the last command in the deploy step.

[9:22] This example will get you all set up. Make sure to check out the repository.