Retire review deploy and add live Actions

README.md

@@ -38,14 +38,26 @@ The installer creates the `importarr` system user when needed, installs a virtua
 For a machine that should stay current with the repository, use the installed repo-upgrade helper:
 
 ```sh
-sudo -n sh /opt/importarr/repo-upgrade.sh v1.2.3
+sudo -n sh /opt/importarr/repo-upgrade.sh
 ```
 
-The helper requires the intended release tag and a clean Git checkout at `/opt/importarr/repo` (override with `IMPORTARR_REPO_DIR` only for a nonstandard installation). It fetches tags, checks out that exact tag in detached-HEAD state, reinstalls the package, records tag/SHA provenance, and restarts `importarr.service`; it never installs an arbitrary branch head.
+The helper requires a clean Git checkout at `/opt/importarr/repo` (override with `IMPORTARR_REPO_DIR` only for a nonstandard installation). It fetches and checks out exactly `origin/main`, reinstalls the package, records commit provenance, and restarts `importarr.service`.
 
-Installed deployments can expose the same operation through the authenticated API. `GET /api/control/update-check` queries the latest release from `IMPORTARR_UPDATE_RELEASE_URL` (default: this repository's Gitea latest-release API) and compares it with the installed release recorded in `/opt/importarr/build.env`. `POST /api/control/update?expected_tag=v1.2.3` verifies that the latest release is the caller's expected tag, appends that exact tag to the configured command, and schedules it in a detached process after returning. A mismatch returns `409` without scheduling an upgrade. The upgrade helper holds an exclusive lock across fetch, checkout, install, provenance update, and service restart, so concurrent requests cannot overlap. Poll `/health` and `update-check` until the new process is healthy and reports the expected tag. The systemd default is the working-directory-independent `/bin/sh /opt/importarr/repo-upgrade.sh`; configure `IMPORTARR_UPDATE_COMMAND` only when the helper is installed elsewhere. The web UI Start, Stop, and Restart controls target `manual-media-import.service` by default; configure `IMPORTARR_START_COMMAND`, `IMPORTARR_STOP_COMMAND`, or `IMPORTARR_RESTART_COMMAND` when those defaults need a wrapper such as sudo.
+When bootstrapping an existing tagged-release installation, invoke the new helper directly from the checked-out repository once instead of invoking the old installed copy:
 
-Release-worthy changes should be committed, tagged with SemVer (`v0.1.1`, `v0.2.0`, ...), pushed with tags, then installed from the tagged checkout or artifact.
+```sh
+sudo -n sh /opt/importarr/repo/deploy/repo-upgrade.sh
+```
+
+That first run installs the repository-based helper at `/opt/importarr/repo-upgrade.sh` and removes the obsolete `IMPORTARR_UPDATE_COMMAND` entry from the existing env file. Subsequent deployments can use the installed helper normally.
+
+Pushes to `main` run `.gitea/workflows/deploy.yml`. Python tests, frontend tests/build, and deploy-script syntax checks must pass before the deploy job can start. The workflow then connects only to the configured live SSH host, refuses a dirty checkout, updates `/opt/importarr/repo` to `origin/main`, and invokes that checkout's upgrade helper through passwordless sudo.
+
+Configure repository Actions secrets `IMPORTARR_DEPLOY_HOST`, `IMPORTARR_DEPLOY_PORT`, `IMPORTARR_DEPLOY_USER`, `IMPORTARR_DEPLOY_SSH_KEY` (a dedicated private key accepted for the deployment account), and `IMPORTARR_DEPLOY_KNOWN_HOSTS` (a pinned `known_hosts` line for the live host). The deployment account must allow the workflow's fixed `/bin/sh -c` deployment command through `sudo -n`. The live checkout must be able to fetch `origin/main`; do not put a Git credential in the workflow. Protect `main`: require pull requests and the workflow test job, restrict direct pushes and force pushes, and limit workflow/secret administration to trusted maintainers. Gitea Actions executes repository code before deployment, so deployment secrets must not be exposed to pull-request workflows and untrusted contributors must not be permitted to push to `main`. These controls are repository-administration prerequisites; this workflow cannot enforce them itself.
+
+The upgrade helper holds an exclusive lock across fetch, checkout, install, provenance update, and service restart, so concurrent deployments cannot overlap. The web UI Start, Stop, and Restart controls target `manual-media-import.service` by default; configure `IMPORTARR_START_COMMAND`, `IMPORTARR_STOP_COMMAND`, or `IMPORTARR_RESTART_COMMAND` when those defaults need a wrapper such as sudo.
+
+Release-worthy changes should be committed and pushed to `main`; tags remain optional release metadata and are not the deployment trigger.
 
 ### Required setup
 
@@ -78,8 +90,6 @@ Release-worthy changes should be committed, tagged with SemVer (`v0.1.1`, `v0.2.
 - `POST /api/control/stop`
 - `POST /api/control/cancel-current`
 - `POST /api/control/restart`
-- `GET /api/control/update-check`
-- `POST /api/control/update?expected_tag=v1.2.3` (`expected_tag` is required)
 - `POST /api/queue-items/{id}/action` with `{ "action": "retry|ignore|remove" }`
 - `POST /api/import/run-now`
 
@@ -103,42 +113,6 @@ lucide-react for icons. Run `npm --prefix frontend run dev` for Vite's developme
 server (it proxies API calls to port 8765), or build before running FastAPI so the
 production assets are written to `importarr/static`.
 
-### Persistent local review environment
-
-The review Compose stack builds the current working tree, including uncommitted
-UI/API changes, and stays running for pre-commit or pre-push inspection. It is
-separate from production: the web port is bound to localhost by default, state and
-sample media live under the ignored `.review-data/` directory, external Arr/SAB
-services are not required, and service-control/update commands are safe no-ops.
-
-```sh
-deploy/review/review.sh up       # build current files and start in background
-deploy/review/review.sh update   # rebuild changed files and recreate as needed
-deploy/review/review.sh status
-deploy/review/review.sh logs     # follow logs; Ctrl-C leaves the stack running
-deploy/review/review.sh stop     # stop containers, preserving them and data
-deploy/review/review.sh down     # remove containers/network, preserving data
-deploy/review/review.sh reset    # remove stack and all local review data
-```
-
-On first use the wrapper copies `deploy/importarr.review.env.example` to the
-ignored `deploy/importarr.review.env`. Adjust `REVIEW_PORT` there if port 18765
-is occupied, then review `http://127.0.0.1:18765/`. For review from a trusted
-internal network, set `REVIEW_BIND_ADDRESS` to the host's LAN address and use
-that address in the URL. Do not use `0.0.0.0` or expose this review stack to an
-untrusted network; the safe default is `127.0.0.1`. To exercise imports without
-real integrations, place disposable folders in `.review-data/downloads/`; movie
-and TV destinations are `.review-data/movies/` and `.review-data/tv/`.
-Each checkout gets its own Compose project and image name, so worktrees do not
-replace each other's containers or images. Read-only and cleanup commands do not
-create the local env file when it is absent.
-
-Agent workflow: run tests, run `update`, confirm `status` reports healthy, and
-leave the stack running for the reviewer. Reviewer workflow: inspect the UI and
-API, use `logs` when needed, and use `down` after review (or `reset` when the
-saved review state is no longer useful). Re-run `update` after every working-tree
-change that should be reviewed.
-
 ## Operations
 
 Importarr intentionally does not document private deployment topology, hostnames, reverse proxies, monitoring, backups, or operator workflows in this repository. Keep those details in your own ops runbooks.