search

ckolderup / postmarks

a single-user bookmarking website designed to live on the Fediverse
https://postmarks.glitch.me
MIT License
466 stars 39 forks source link

`npm run update` to automate pulling down the latest code from git #156

Open ckolderup opened 1 year ago

ckolderup commented 1 year ago

People who don't know how to manage git should be able to receive updates to Postmarks. I've been talking to some other folks at Glitch and it sounds like the best way to support Glitch installs (and one that should be plenty useful to non-Glitch installs as well) is to provide some npm scripts that manage this.

Proposal outline:

  1. npm run update, given that a git upstream has been set, should take the current git HEAD, move it into a backup branch, then (force-?)pull from the main branch (if we eventually change release strategies, we can change this script to do something more nuanced to find the current installed version & grab the latest version that we believe we can safely update the user to)
  2. A companion npm run git-setup should exist to prompt the user for a URL to a git remote, defaulting to the main postmarks repo, giving someone an opportunity to specify their own fork if they're choosing to manage the project that way.
  3. Because we have the backup branch, we can provide manual instructions for restoring the branch if need be.

In general everything relevant data-wise should be safe given that .gitignore includes the directory, but maybe we should also make backups of .db files?

It seems like there might be previous work here in other projects–curious if anyone knows of any other relatively small projects that have already handled something like this (less interested in something as heavyweight, or as Docker-oriented, as Mastodon)

ckolderup commented 1 year ago

Instructions I've given to a few people which have yielded mixed success:

git remote add upstream https://github.com/ckolderup/postmarks
rm .data/.keep
git pull upstream main

I just did a remix on Glitch to test this out and it seems to work. The second step is necessary because it looks like there's a problem with the gitignore strategy I have right now of keeping the .data directory in the git repo by using an empty .keep file, then trying to .gitignore everything except that file. This blog post has an interesting alternative approach, replacing the .keep with a subdirectory .gitignore that ignores everything except itself. We should probably switch to using that, and see if that at least lets us remove the second line of that recommendation.