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>
149 lines
6.0 KiB
Markdown
149 lines
6.0 KiB
Markdown
# 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)
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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.
|
|
|
|
```bash
|
|
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](https://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.
|
|
|
|
```bash
|
|
# 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 |
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
./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.
|