Explore options for avoiding redeployments of unchanged apps

[taesungh]

Derived from HackAtUCI/zothacks-site#209:

Because of our quota in Vercel of 100 builds per day, it would be nice if we could avoid redeploying the different projects (Site and Sanity) both in previews and production if nothing has changed in that specific app since its last deployment (and vice versa for the site although less often there).

Vercel has a mechanism for skipping unaffected projects in monorepos, but that requires connecting the repository which we cannot do on the Hobby team.

This feature is only available for projects connected to GitHub repositories.

We might be able to manually replicate that by setting up ignoring the build step based on turbo-ignore. However, skipping the build still counts as a deployment.

Canceled builds initiated using the ignore build step do count towards your deployment and concurrent build limits

Therefore, we would need to somehow replicate the feature from the Actions workflows.

[IanWearsHat]

Could we run git diff --quiet HEAD^ HEAD ./apps/specific-project at the top of the action once for site and once for sanity, check its output, and then see if we should run a deployment or not? I might be oversimplifying a lot here.

[taesungh]

My initial thought was we can run npx turbo-ignore <package> as one step of the workflow which does something similar using --filter="{package}...[HEAD^], but unfortunately, it seems that doesn't account for the task inputs: vercel/turborepo#4678. This means non-functional changes such as updating a README file or a unit test will trigger a redeployment.

We might have to implement our own hash check to replicate the desired behavior.

[taesungh]

Been creating a new reusable action in HackAtUCI/super-turbo-ignore#1 that can also be used by HackAtUCI/zothacks-site in the future. Once that is ready, will update the workflows in this repository to use that action as a job step and also reduce duplication in the workflows by using a matrix strategy.