Files
recurring-checklist/LAPTOP-SETUP.md
T
Waters ChurchandClaude Opus 5 5770db370b Document the repo, and stop server/data at the gitignore
The setup notes described moving the project as a tarball and never mentioned
git, because until now there was no repo. They now lead with the clone URL and
what a push needs — the credential helper, a token, and the hostname rather
than 10.3.8.90, since the stored credential is keyed to the hostname and a
remote written against the bare IP prompts every time.

server/.gitignore only excluded data/*.json, which was enough for the checklist
file and nothing else. Running the server locally creates data/uploads, data/docs
and data/backups beside it, so an attached PDF or a backup would have been
committed on the next add. The whole directory is ignored now. That data lives
on the NAS; a stale copy of it restored over production is the accident worth
designing out.

Also records that the NAS password is a keychain item rather than a file, so a
future machine knows to store it instead of hunting for the line that used to
be in build-deploy.sh.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-24 13:05:30 -04:00

6.0 KiB

Moving checklist development to another Mac

The project folder is most of it, but three things live outside it, and one thing should deliberately stay on the Mac Studio.


Source control

The project is in git, on the church Gitea:

http://chronicles-ab.waterschurch.org:3000/christian/recurring-checklist (private)

git clone http://chronicles-ab.waterschurch.org:3000/christian/recurring-checklist.git

That replaces the tarball below as the way to move the code — but only the code. Git deliberately carries none of the secrets and none of the live data, so the "Restore the secrets" section further down still applies to every new machine, and always will.

Pushing needs a credential for the Gitea. Store it once per machine and the osxkeychain helper answers every push after that, unattended:

git config --global credential.helper osxkeychain

The first git push then asks for the username (christian) and a personal access token with write:repository, generated at Settings ▸ Applications in the Gitea web UI. Write the remote with the hostname, not 10.3.8.90 — the stored credential is keyed to the hostname, and a remote written against the bare IP will prompt every time.

The forge is LAN-only. Cloning and pushing need the church network or a VPN into it, the same as a web deploy.

What to copy

checklist-app-transfer.tgz — the whole project minus node_modules, build output and secrets (all of which are either regenerated or restored separately). Unpack it wherever you like; nothing depends on the path except the two config files noted below.

mkdir -p ~/Documents && tar -xzf checklist-app-transfer.tgz -C ~/Documents

What the laptop needs installed

How
Xcode Mac App Store. Then sudo xcodebuild -license accept and open it once.
Node 20+ nodejs.org installer
JDK 21 see below
Android SDK see below

No Homebrew and no CocoaPods are needed — iOS uses Swift Package Manager deliberately, because the system Ruby is too old for CocoaPods.

# JDK 21
curl -L -o /tmp/jdk.tar.gz 'https://api.adoptium.net/v3/binary/latest/21/ga/mac/aarch64/jdk/hotspot/normal/eclipse'
mkdir -p ~/.jdks && tar -xzf /tmp/jdk.tar.gz -C ~/.jdks && mv ~/.jdks/jdk-21* ~/.jdks/temurin-21

# Android command-line tools + SDK
curl -L -o /tmp/cmdtools.zip 'https://dl.google.com/android/repository/commandlinetools-mac-13114758_latest.zip'
mkdir -p ~/Library/Android/sdk/cmdline-tools && unzip -q /tmp/cmdtools.zip -d /tmp
mv /tmp/cmdline-tools ~/Library/Android/sdk/cmdline-tools/latest
yes | ~/Library/Android/sdk/cmdline-tools/latest/bin/sdkmanager --sdk_root="$HOME/Library/Android/sdk" --licenses
~/Library/Android/sdk/cmdline-tools/latest/bin/sdkmanager --sdk_root="$HOME/Library/Android/sdk" \
  "platform-tools" "platforms;android-36" "build-tools;36.0.0"

# Project dependencies
cd ~/Documents/recurring-checklist-app/mobile && npm install
cd ../server && npm install

Then edit mobile/android/local.properties so sdk.dir points at the new machine's home directory — it is machine-specific and will be wrong after a copy.

Restore the secrets

They are not in the transfer bundle on purpose. They are already in checklist-signing-backup.dmg (Google Drive → Apps/Backups). Open it and:

From the DMG Goes to
android/upload-keystore.jks <project>/mobile/keystore/upload-keystore.jks
android/keystore.properties <project>/mobile/keystore.properties
ios/AuthKey_NXR7767SYK.p8 ~/.appstoreconnect/private_keys/
ios/ios-signing.config <project>/mobile/ios-signing.config
— <project>/server/.env — copy from the Studio; it is not in the DMG
chmod 600 ~/.appstoreconnect/private_keys/AuthKey_NXR7767SYK.p8

The NAS password is a keychain item, not a file. build-deploy.sh and backup-to-drive.sh used to carry it in plaintext; they now read it from the login keychain, so it stays out of the repo and rotating it is one command instead of a history rewrite. Store it once per machine — omit the value and security prompts for it, so it never reaches your shell history:

security add-generic-password -U -s checklist-nas -a Christian -w

Both scripts also accept NAS_PASS from the environment, for anywhere without a keychain.

Then fix the absolute path inside keystore.properties:

storeFile=/Users/<you>/Documents/recurring-checklist-app/mobile/keystore/upload-keystore.jks

The iOS distribution certificate is not copied. Sign into Xcode ▸ Settings ▸ Accounts with the same Apple ID and run ./release.sh --ios; -allowProvisioningUpdates mints a new certificate for the new machine automatically. Nothing needs exporting from the old keychain.

Check it works

./mobile/scripts/verify-asc-key.sh        # authenticates against App Store Connect
cd mobile && node scripts/sync-web.js     # rebuilds www/ from server/public
cd android && . ../scripts/env.sh && ./gradlew :app:bundleRelease --no-daemon

A signed .aab means Android is fully restored. ./release.sh --ios proves the Apple side.


What must STAY on the Mac Studio

The nightly off-site backup. backup-to-drive.sh plus the LaunchAgent org.waterschurch.checklist-drive-backup should keep running here, not on the laptop:

  • a LaunchAgent only fires while the machine is awake and logged in — a laptop that sleeps or goes home silently stops backing up, and the failure is invisible
  • it needs the LAN to reach the NAS at 10.1.1.5

Leave both in place on the Studio. If the laptop ever becomes the only machine, move the script and reinstall the LaunchAgent there — and check the log afterwards.

The other thing that needs the LAN

build-deploy.sh (and therefore ./release.sh) pushes to the NAS at 10.1.1.5. Web deploys only work on the church network. Off-site you can still build and upload the iOS and Android apps — those only need the internet — but ./release.sh --web will fail until you are back on the LAN or on a VPN into it.