DEV Community: John McGuin

Github Actions Dynamic Matrix

John McGuin — Fri, 23 Aug 2024 00:00:00 +0000

From the jump I should call out that I'm not a DevOps professional. There are quite possibly dragons in this solution; I may have done things weirdly. But, it worked well for me, and I'd like to share it for posterity and my own future reference. If you just want to consult the end solution, you can find that here.

Problem

I am working on a template repo called unicorn that is designed to make it easier to deploy websites alongside job applications. It is a monorepo to house many Astro websites with the same template and UI. Theinitial iterationof the workflow simply used a matrix for the deployment jobs. This works perfectly well, but in practice, as I've used the template in my own job hunt, in a matter of a couple of weeks I already have a fairly large number of sites deployed. In this iteration, every website is deployed on every push to main. These are fairly quick jobs, but there is no need to run them. Better to save compute and energy and to only deploy the sites that are changed.

High level solution

At a high level, the solution is to maintain a mapping of monorepo packages (the name of the directory found in sites/<site>) to Pages projects. The workflow will need to reference this configuration, whether it is expressed in the yml file itself or in a configuration file. The workflow will also need to determine what has changed. If just a site was changed, it should just deploy that site. If the common UI package has changed, then all sites should get deployed, for example. The workflow now has an additional job called "prepare". Prepare will prepare the matrix and the "publish" job will depend on its outputs. So the workflow should: check changes -> compare changes to full configuration sites -> deploy relevant sites.

Configuration

This is the area that I am most curious if I ended up with a weird solution. The job needs a mapping of package names (the directory) to the name of the Cloudflare Pages project. These could differ and should not be tied together, but at the end of the day, we need to know how to map a certain directory to a Pages project. I am unsure if there is a more native way to do this within the workflow syntax, but I could not determine it. I ended up using a JSON file sites.json for the users to configure this mapping. This is accomplished byadding a stepin the "prepare" job that reads thesites.json file and sets it as an environment variable to $GITHUB_ENV. In the sites.json, the keys are the directory names and the values are the Pages project names.

Determine changes

To determine the changes, you could do this a number of ways, but the method I landed on was to use an existing action called paths-filter from GitHub userdorny. Thanks dorny! This had a nice API and it's nice to have less code to parse and grok. I won't go into a detailed description of the action here, but thenew steporganizes git changes to be returned by user specified filters that can be queried to help develop logic flows in your pipelines. Here, I am querying by dependency changes and core UI package changes which would require re-deploying all sites. Otherwise, there will be 0 to many deployments based on whether sites have changed or not.

There was one feature I was kinda missing / hoping for with paths-filter and that was to specify what type of data to return for the filters. For example, for the sites filter, I am only really concerned with the immediate children of sites. I don't think there was a way to do this, so I did write afollow up stepwhich takes the outputs from paths-filter and sets a new environment variable to $GITHUB_ENV which is the unique sites changed, only the directory of the site.

Script building the matrix

To recap, we now have the user configured sites that they want to deploy, the unique sites that have changed from a git perspective, and a nice workflow API to check if sites have changed, dependencies, or core packages have changed. With all this in place, we can write a script that can build the matrix of sites to deploy. I am not very good with bash scripting, so I wrote a node script instead. Thebuild dynamic matrixstep checks the output of paths-filter and calls the node script to build the matrix for all sites if deps OR core packages have changed. If sites have changed, build a matrix for only the target sites. If neither is true, then do not run the script and simply set "continue" to false. "Continue" is an output of the job for the publish job to consult. As I understand it, there is no native way in the workflow syntax to say "this was successful, but don't continue the rest of the pipeline". Hence, the explicit "continue" output. The script that builds the matrix ishere, but the gist is that it needs to return the matrix data for the publish job. It leverages theinclude syntaxfor a matrix job.

Outcome

What we now have is a workflow that can publish only the sites that need to be deployed. If not, it will exit successfully after the prepare job and the workflow will not run the publish job. This is exactly what we were hoping for. I found this to be a really good little project to expand my knowledge of GitHub Actions. Hopefully you've found this to be a little helpful in your own Actions adventures as well.

Managing Multiple Apps On Fly.io

John McGuin — Mon, 12 Aug 2024 00:00:00 +0000

TLDR; remove the app key in fly.toml to get prompted to select the application when running fly commands that depend on an application.

There is a time and a place for running your own VPS or VPC, but when I am in the mode of wanting to focus on writing and shipping application code as a solo developer, I don't think there is anything wrong with using a PaaS. The platform I've been reaching for recently is fly.io. I was initially drawn to check out fly because they're an Elixir shop (😍). I was impressed by the offering. While I don't use their database services, for deploying applications, they've struck a really nice balance of simplicity and power. Further, by deploying with docker based Elixir / BEAM releases, I should be able to fairly easily port this to a different cloud environment or VPS without too much fuss.

As with any tech you are new to, the surface area of the product and APIs can at times be overwhelming. As a new user with many apps on Fly, I was bit by accidentally running commands against the wrong application a few times, leading to unwanted releases, unwanted scaling, etc, or at worst, broken releases. While the ability to deploy, provision, etc, directly from the command line is a powerful tool for the solo developer, it's not without it's drawbacks. You have to be careful. There are numerous commands that I wish for a --dry-run flag, or that they would provide a confirmation stage before execution.

My first workaround was to write bash scripts for my projects that wrapped the fly commands I wanted to be extra careful with. These scripts would require an environment name, or application name, for example. This worked fine, but it both required being written and also required me and any future developers on the project to use this script for deployments. Maybe not a big deal once integrated in CD automations, but still more open to error than is desirable. There was a simpler, more error proof, more blessed path that I didn't initially know about. That solution is to simply remove the app key from the fly.toml file. Now, when you execute fly commands that require an application to run against, the cli will prompt you for the application before it executes.

Configuring Ngrok With A Static Domain

John McGuin — Fri, 09 Aug 2024 00:00:00 +0000

I have been working on a Shopify app called File Vault Pro to offer a better experience selling digital goods on Shopify. For this app, I used the Shopify CLI to create a Remix BFF, while writing the core application server in Elixir / Phoenix. The Shopify CLI automatically configures the Shopify application environment and handles a dynamically named https tunnel (via Cloudflare tunnels) really well, but I also needed an https tunnel to the backend service (I am using ngrok here), which could not be dynamically updated. This would require running the backend server with ngrok, updating the environment variable for the API endpoint with the dynamically generated URL in the Remix project and then running the Remix server. Not the end of the world, but also not the most enjoyable workflow. Then I found that you can use custom static domains with ngrok.

Create Custom Domain

Ngrok now offersone free static domain. First, create a custom domain in ngrok by following the steps outlined in the blog post referenced above.

Update Ngrok Configuration File

With the new static domain name in hand, next we'll have to update or create the ngrok configuration file. By typing ngrok config check you should see the file path to the ngrok configuration file. Now, open that in your editor of choice. Alternatively, running ngrok config edit should open or create and open the configuration file in your system's default editor. The ngrok configuration file is a .yml file. Full documentation for ngrok configuration options can be found in theirdocumentation. For example's sake, here is a basic version that achieves our desired outcome:

version: '2'
authtoken: ' *********************'
tunnels:
  shopify_backend:
    proto: http
    addr: 4000
    domain: <your-domain>.ngrok-free.app

You can obtain your auth token via the ngrok dashboard. Give the tunnel whatever name you would like. I called mine 'shopify_backend'. With the static domain provisioned and the configuration file saved, you should now be able to start your service by name like this:

ngrok start shopify_backend

Now, you don't have to worry about starting your services in the right order, or updating the environment variable that references your ngrok service every time you start the dependent service.

Unicorn

John McGuin — Wed, 07 Aug 2024 00:00:00 +0000

Introducing Unicorn, a monorepo template built on GitHub Actions and Cloudflare to help you stand out in your job applications by deploying a static site for each job application.

Create repo

First, you'll need to clone the template repository to your own, working repository.

Clone into repo

Next, clone your new repository to your local dev machine and install dependencies.

npm install

Create a site

The easiest way to create a site is to use the npm run new command. This is the basis of creating a new site based on the template site that lives at sites/template. You can consult the help docs by running npm run new -- --help. Take a minute to read the output.

$ npm run new -- --help
> unicorn@0.1.0 new
> scripts/new_site.mjs new --help

Usage: Unicorn CLI new [options]

Create a new website

Options:
  -d, --dir <name>      name of the directory
  -j, --job <title>     job title you are applying for
  -c, --company <name>  name of the company. This will be used in website copy.
  -h, --help            display help for command

The options themselves should be fairly straightforward. What is happening behind the scenes is that the directory flag will make a copy of the template site and create a new site at sites/. The job and company flags will be used for text substitions throughout the website’s copy. This should inform the copy that you write for your own version of the template site. The template site is meant to be customized! It is recommended to write the template site out to minimize the amount of work required after running the script. When customizing the template, there is an assumption that the script makes, which is that the template is substituting all instaces of the string “Company” with the value passed into the --company flag. It replaces all instances of the string “Job Title” with the --job flag. Write your template accordingly! Alternatively, you can customize the script to suit your exact needs. This is not meant to be a silver bullet but more of a starting off point for your own personal automations to this process.

When you are done with the npm run new script, you have a new site! The output states how exactly to run your new site. The only manual steps that you have are to:

Create a Cloudflare Pages project
Add an entry to sites.json where the key is the directory name and its value is the name of the Cloudlfare Pages project.
Customize the site (resume, copy, etc) to the specific job application.
Push and monitor the action to make sure the deployment was successful. If everything went right, you should now have a new site live.

Deployment

You've developed your website and are ready to deploy it. First, either create or login to your Cloudflare account. In your Cloudflare account, navigate to "Profile" -> "API Tokens" -> "Create Token". Under the "Custom token" section, click to create a custom token. Give the token a name and the edit permission to Cloudflare Pages. Copy this token and navigate to your GitHub repository. Add a GitHub secret named 'DEPLOY_TOKEN', pasting the token from the previous step as the value. Add another secret called 'CLOUDFLARE_ACCOUNT_ID'. Obtain the value for this from the Cloudflare dashboard. Navigate to the "Workers and Pages" section in your Cloudflare account. You should be able to copy the account id from the sidebar of this web page. The workflow will use these secrets to deploy your websites to your Cloudflare account.

While in the Cloudflare dashboard, create your first site. Navigate to "Workers and Pages". Select "create application". Select "Pages" tab. Select "Create using direct upload". Select "Upload assets", although we will be skipping the actual upload of assets (the GH action workflow will do this for us, we just need to create the pages "project" at this point). Give the project a name, and select "Create project" without uploading assets. Take note of the project name you provided. Update the GitHub action's matrix property with this value. You should update the 'project' key.

At this point, everything should be setup for a deployment to succeed. To test this out, push your working repository to the GitHub remote and watch the action run.

DNS

DNS is out of scope for this post. For my own job applications, I use Cloudflare name servers and deploy each website as a subdomain to a personal TLD, which works quite well.

If you have any issues following this post, please open an issue on GitHub.

Environment Variables In Shopify Checkout Ui Extension

John McGuin — Thu, 27 Jun 2024 00:00:00 +0000

This post refersShopify Checkout UI extensions. Seethis post for a brief introduction to UI extensions.

Problem

One big limitation of the Shopify UI extensions is that there is no native way to use environment variables, an important principle when making apps. My use case, which I imagine is a very common one, is providing my frontend extension code with an api endpoint that will vary across development, staging, and production environments.

Solution

The solution I landed at is to kind of hack in environment variables into the code during build time. This will happen by:

writing a template file with all of your environment variables
depending on a configuration file in your code which holds your environment variables
writing a script that creates that runtime file using the template file as a template
calling that script at build time, setting in your environment variables for the script to consume
.gitignore your runtime file

Template File

First, create a template file. Place this in your extension's src directory. Mine lives atsrc/config/config.template.txt. The contents are: export const API_URL = "$API_URL";. That's it.

Depend on Config File (Source Code)

In your source code which depends on the environment variable, pull in your exported variable(s) from a dependency we'll call config.ts. This file will live right next to theconfig.template.txt file. Don't create this, though, the script will. My import looks like:

import { API_URL } from './config/config';

Script It

Now that the runtime dependency is in place, we need to write a bash script to create the runtime dependency and populate it with our environment variables. I put my project scripts in a scriptsdirectory at the root of the project. I gave my script the verbose namesetup_ui_extension_environment.sh. It looks like this:

#!/usr/bin/env bash
# template file
template="extensions/<your-extensions-name-here>/src/config/config.template.txt"
# generated file
config="extensions/<your-extensions-name-here>/src/config/config.ts"
# make sure that the API_URL environment variable is set
if [-z "${API_URL}"]; then
    echo -e "\033[0;31mMust set API_URL environment variable"
    exit 1
fi

# generate the runtime file based on the template, using envsubst
envsubst < "$template" > extensions/<your-extensions-name-here>/src/config/config.ts
# output what you did
echo -e "\033[0;32mWrote $API_URL as API_URL from $template to $config"

API_URL is my only environment variable at the moment, but you can imagine extending this to support many others.

Invoke The Script

This manual will only cover development, but the concepts apply across environments and deployments. Make sure to invoke this script when you are building your extension code. My new package.jsondev command looks like this:

"scripts": {
    "dev": "API_URL=https://my-app.ngrok-free.app npm run env:setup && npm run config:use dev && shopify app dev",
    "env:setup": "./scripts/setup_ui_extension_environment.sh"
}

Don't mind the extra config instructions, the important bit is to:

set the environment variable (i.e. API_URL=https://my-app.ngrok-free.app)
invoke the script (i.e. npm run env:setup)
before running the shopify dev environment (i.e. shopify app dev)

.gitignore it

It's generally prudent to .gitignore generated files. We don't want to commit this because we it will vary across environments, and maybe even developers on your team, etc. It's a build time concern only.

Authenticated Requests From Shopify UI Extensions

John McGuin — Sun, 16 Jun 2024 00:00:00 +0000

Shopify has a notion ofCheckout UI extensions. These provide hooks, or targets, to write custom user experiences during the checkout flow. For my Shopify app,File Vault Pro, users are able to associate files with specific products and variants. I needed to leverage UI extensions to provide download access during the checkout experience. There would be two targets for my use case, the "Thank You" and "Order Status" pages. This guide will focus on how to make an authorized request from an extension directly to your API. Creating and configuring an extension is beyond the scope of this guide, but there is plenty of documentation to do so. This guide also assumes an app created with the shopify remix template.

Configuration

The extensions run in a sandboxed environment and need to be given a couple of permissions. First, from within your partners dashboard, select the app you are developing. From there, select the "API Access" tab. Scroll down and make sure to enable the "Allow network access in checkout and account UI extensions" section. Within your shopify.extension.toml file, make sure to uncomment the line marked network_access = true. This gives your extension the "capability" to make network requests.

Obtain Token

From within the code of your extension, grab the session token with the hook useSessionToken. Make sure that the import path is correct. For example, for the "Order Status" page, the import path is "@shopify/ui-extensions-react/customer-account". Consult the documentation to ensure you are using the correct import path given your target. Now that you have verified that you can get the session token on the client side, it's time to move towards the server.

Server

In my stack, the Remix app serves as a Backend for Frontend (BFF) with the main application code running in a separate service. Instead of proxying the request through the Remix app, I opted to go directly to the backend API. This involves a couple of steps:

From the partner dashboard, select the app and grab the client secret. Add this as an environment variable to your server. This will be used to verify the incoming JWT passed from the extension.
This will vary depending on your server, but the gist is that you will want to verify the JWT for any of the routes that you've created for the extension to consume. This will likely take the form of some sort of middleware. Followthe instructionsto validate the JWT. It is highly recommended to find a JWT validation library to help with this process. I am using Elixir's Joken library which greatly simplifies this. Consult JWT.io to identify a language specific library for you.
CORS - you'll also need to enable CORS for the given routes that you are exposing to the extension. These will have a dynamic origin, so origin cannot be depended upon fully as is for CORS configuration.

Integration

Test. At this point, if everything is configured correctly, you should be able to make an authenticated request to your API from the extension. Within the extension code, make a fetchrequest passing in the session token as an authorization header.

let res = await fetch(`URL`, {
    headers: {
        Authorization: `Bearer ${token}`,
    },
    mode: 'cors',
});

Alternatives

I haven't explored these options, but I think that you should be able to call the Remix backend in a similar manner. I would guess but have not verified that an app created with the CLI is likely configured to automatically verify the JWT. I believe that anApp Proxy could also be a viable option here, but have not explored these in depth.

Docker Dadbod Ui

John McGuin — Fri, 14 Jun 2024 00:00:00 +0000

In normal mode, invoke :DBUI, establish a new connection with A. When prompted to enter a connection string, follow thePG spec.

e.g. postgresql://<db-user>:<db-password>@localhost:5432/<db-name>

Shell into Containerized PostgreSQL Database

John McGuin — Fri, 14 Jun 2024 00:00:00 +0000

Shell into the running container:

docker exec -it <container-id> /bin/bash

Run psql to connect to the database:

psql -d <db-name> -U <user>

Time Travel Directories

John McGuin — Sun, 14 Jan 2024 00:00:00 +0000

The first time I saw somebody use cd - my mind was blown. If it's new to you, cd - will change to your previous directory. The shell is tracking a stack of recent directories, which can be seen via the builtin dirs command. You can also directly interface with the directory stack via pushdand popd. This is so cool and it's the backing mechanism that cd - uses. With that new knowledge, I created a small zsh function to help me time travel to any directory on the stack, instead of just the most recent.

function travel() {
    local options=()
    while read -r dir; do
        options+=("$dir")
    done < <(dirs -p)

    select dir in "${options[@]}"; do test -n "$dir" && break; echo "Invalid Selection"; done
    eval cd "$dir"
}

When this function gets invoked, you're prompted to select an option from the directories on the stack and it will navigate back to it.

Better Navigation Experience With ZSH cdpath Variable

John McGuin — Wed, 10 Jan 2024 00:00:00 +0000

In *nix systems, the cd command lets us navigate the filesystem. There are a few places that I visit most frequently though. For me, it's my Projects directory, my Brain directory (obsidian), and then a Playground directory is where I throw experimentation or throw away code. That, and my $HOME. You can add or experiment with these changes and they can be added to your .zshrc or .bashrc.

Aliases

I use these aliases as navigation helpers to go backward in the filesystem.

alias ..="cd .."
alias ..2="cd ../.."
alias ..3="cd ../../.."
alias ..4="cd ../../../.."

They should be pretty straight forward, but these basically say go backward .. n levels. Of course it's just hard coded but I'm never really needing much more than that. In combination with the cdpath modification, system navigation becomes beautiful 🤌.

cdpath OR $CDPATH

In linux, when a cd gets executed, the $CDPATH environment variable is consulted. The $CDPATH is similar to the $PATH variable in structure and behavior. If it's not set explicitly, the behavior just defaults to operating from the current directory. However, you can customize it for much prosperity, good fortune, and good times. I use ZSH so my example will use ZSH's cdpath which takes a list instead of a string, but the example can be easily modified to bash or your shell of choice.

cdpath=(. $HOME $HOME/Projects $HOME/Brain $HOME/Playground)

This extends the cdpath to include all of these additions. What this means in practice is that I can still have normal cd behavior from the current directory, but I can also cd directly into anything in any of the other paths. For example, if I have a project at $HOME/Projects/blog, from anywhere on the system, I cancd blog, or I could cd Projects/blog.

How To Use Virtual Environment In Jupyter Notebooks

John McGuin — Fri, 06 Oct 2023 00:00:00 +0000

I've written almost no Python but have recently been dabbling a little bit to explore some of the AI tools such as langchain. I recently had the need to write a web scraper and thought it would be a good time to practice a little Python since it seems to be a great tool and choice for that domain. My goal was to write a simple script that would take a base URL, extract some data, paginate, and run the same extraction function until the last page. I wanted to write all results to a csv that I could then explore further. After creating the csv, I wanted to be able to explore the data in a Jupyter Notebook. It took me a while to figure out how to isolate my notebook dependencies to the virtual environment. Maybe this post will be found by other beginners trying to do the same.

Creating the virtual env

First, I created the virtual env with venv by running

python3 -m venv env

This provided me with a virtual environment for my scraper project. I activated the virtual env by running:

source /env/bin/activate

If these steps were successful so far, you should see the name of your virtual environment in your shell prompt. From here, you should have python and pip in your virtual environment's path. Now you can install your dependencies for your project.

Creating a custom Jupyter kernel

Fast forward to the point where you have a working Python project. You've packaged up your dependencies for the project and now want to be able to run this virtual environment from within a notebook. This is the part that had me stumped for a little while. You likely need to install ipykernel which is a package for creating Jupyter notebooks Python kernels. Make sure to activate your venv and then in the active virtual environment shell, install ipykernel

python -m pip install ipykernel

Once the dependency is installed, you can now proceed to create the custom kernel.

python -m ipykernel install --user --name=env --display-name="<some-better-name-you-will-recognize>"

Selecting the custom kernel

After launching jupyter notebook, select "Kernel" -> "Change Kernel"

If you had successfully created your kernel, you should see it referenced here under the display name that you used to flag the kernel (in my case this is called shopify-scraper-env).

Once you've selected your custom kernel, you should be able to import project dependencies without pip installing them globally. If you can't import your dependency, something has likely gone wrong.

Debugging

For me, I built the kernel outside of the venv and the creation was succesful but I didn't have access to my packages. For starters, verify that your kernel was created with

jupyter kernelspec list

If your kernel was created, you should see it listed here. If your kernel was listed, it should have printed out with a path. Navigate to that base path and run the ls command. There should be a kernel.json file. If you look into the kernel.json, you should see which python executable the kernel is using. This should be using the version of python found in your virtual environment and if it's not, you likely need to make sure you repeat the steps to create the kernel from within your activated venv. The kernel.json should look something like this

{
  "argv": [
    "<path>/<to>/<your>/<project>/env/bin/python",
    "-m",
    "ipykernel_launcher",
    "-f",
    "{connection_file}"
  ],
  "display_name": "shopify-scraper-env",
  "language": "python",
  "metadata": {
    "debugger": true
  }
}

Updating dependencies

If you're successfully importing your virtual environment dependencies from your notebook, congrats! You're successfully tinkering but need to add a new library or two for the investigatory work you're doing in the notebook. No worries! Basically repeat the process as before. After installing your dependencies, just re-run the command to generate the kernel. In my experience, after doing this, I was good to go. If this doesn't work automatically for you, you could try restarting the kernel through the notebook GUI.

Deploy Astro To Github Pages

John McGuin — Thu, 28 Sep 2023 00:00:00 +0000

If you are using GitHub to host a public repository, deploying your static Astro site onto GitHub Pages is a quick and easy option to getting your site online.

Create DNS Entry

First, you'll want to add a DNS entry for your subdomain. To do this, navigate to your DNS management dashboard for your domain name and add a new CNAME record where the host name is of the format <your-subdomain> and the entry type is CNAME. You should be mapping this to the canonical name of <your-github-username>.github.io. From the DNS side of things, you should be good to go.

Astro Configuration

Moving into the astro project, next you'll want to open your astro.config.ts file and add a site property to your config object such that you have

export default defineConfig({
    site: 'https://<your-full-domain>'
})

GitHub Configuration

To get the deployment ready from the GitHub side of things, navigate to your repository -> 'Settings' -> 'Pages'. Under the "Build and deployment" section, make sure to select "GitHub actions". Under the "Custom domain" section enter your full domain less the scheme. As an example, instead of https://<your-sub>.<your-second-level>.<your-top-level> instead write <your-sub>.<your-second-level>.<your-top-level>. GitHub will run a DNS check but since we have already created the CNAME record, expect this to pass. If this does not pass, double check the previous steps.

Deployment

The final step is to configure a GitHub Action to deploy the project. GitHub Actions is a powerful CI/CD tool build directly into GitHub. It is a deep subject unto itself, but at a high level, specific repo Events can trigger Workflows. A Workflow is process composed of one or many Jobs. In this case, the thing we want to do is kick off a pages deployment. GitHub Actions workflows are defined in .github/workflows directory, so if this doesn't exist, be sure to create it now. Then create a new file in this directory called deploy.yml. In it, paste the following:

name: Deploy to GitHub Pages

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v3
      - name: Install, build, and upload your site
        uses: withastro/action@v0
        with:
          node-version: 18

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v1

What this does is runs a deployment workflow on the push event to the branch main. It utilizes existing actions and composes them together to build the project and upload it to github pages. From here, you should be all set. Pushes to main should now deploy your astro website to your custom subdomain.