Make deployment reproducible and self-updating

[Isma-L154]

Closes #11
Closes #12

Three related problems with how this bot gets onto a server, all verified against the live EC2 host.

1. Dependencies floated

Every requirement used >=, so two deploys a week apart installed different versions. The live host and the dev box had genuinely drifted from the same file:

Package	Dev box	Live host
lyricsgenius	3.10.0	3.12.2
aiohttp	3.13.3	3.14.3

Everything is now pinned — except yt-dlp, which must float. YouTube changes its player and extractors constantly, and a five-month-old build (2026.3.3) returned HTTP 403 on every YouTube URL until it was updated. The comment in requirements.txt explains this so nobody "fixes" it later by pinning it.

2. yt-dlp had no way to stay current

setup.sh now installs loopify-ytdlp-update.timer, running daily with a randomised delay and Persistent=true so it catches up after downtime rather than silently skipping.

The updater runs as root so it can restart the service, but drops to the app user via runuser for the pip install — otherwise the venv ends up owned by root.

Both paths tested on the live host:

Case	Expected	Result
Already current	log and exit, no restart	PID unchanged (119766 → 119766)
Stale (2026.7.4)	upgrade and restart	yt-dlp 2026.07.04 -> 2026.08.19; restarting loopify-bot, PID 119766 → 120033
venv ownership after upgrade	stays ubuntu	ubuntu:ubuntu .venv/bin/yt-dlp

A failed upgrade leaves the working version installed — a newer dependency is never worth trading a running bot for.

3. The documented update path did not work

deploy/README.md said to run git pull, but the host was deployed by rsync and has no .git:

fatal: not a git repository (or any of the parent directories): .git

This is not a documentation nit — it is why fixes merged to main never reached the server. The yt-dlp zombie in #6 survived 19 days there after proc.wait() had already landed in the repo.

Now: provisioning clones, deploy/update.sh handles updates, and the bot logs what it is running at startup.

Running commit 61919d6 — yt-dlp 2026.08.19, FFmpeg 6.1.1-3ubuntu5, Python 3.12.3

That line survives the service's ProtectHome=read-only / ProtectSystem=strict sandbox, which was the risk worth checking.

The CRLF landmine this uncovered

The shell scripts were stored in the repository with CRLF line endings. Harmless while deployment was rsync from Windows — but the moment the docs say git clone, a Linux checkout gets CRLF, bash reads the shebang as /usr/bin/env bash\r, and the script will not run. Changing the docs would have introduced the break.

.gitattributes pins *.sh / *.yml to LF and the tracked files are renormalised. Verified on a real Linux checkout of this branch:

deploy/launch_ec2.sh         0 CR      bash -n: OK
deploy/setup.sh              0 CR      bash -n: OK
deploy/update-ytdlp.sh       0 CR      bash -n: OK
deploy/update.sh             0 CR      bash -n: OK

A gap found by testing, then fixed

The first version of update.sh failed with git's own "There is no tracking information" wall of text on a host converted from a file copy — the exact situation the conversion instructions produce. The second commit detects a missing upstream and says what to run, and the recipe in both the script and the README now sets it.

Both paths re-verified on the host:

!! Branch 'master' has no upstream, so there is nothing to pull from.
   ...
     git branch --set-upstream-to=origin/main master

==> Fetching...
==> Already up to date.
==> requirements.txt unchanged; skipping dependency install.
==> Restarting loopify-bot...
==> Running commit 61919d6.

End state on the live host

The EC2 was converted to a git checkout as part of this (secrets backed up first; .env and cookies.txt are gitignored and came through untouched at chmod 600). It now runs this branch:

	Before	After
Deployed code	rsync, unknown commit	git checkout, 61919d6
yt-dlp	2026.7.4 (6 weeks stale)	2026.08.19, auto-updating
Zombie processes	1, aged 19d 19h	0
Bot RSS	96 MB	49 MB

That zombie count is the #6 fix confirmed in production, not just in tests.

Verification

• 201 passed locally (21 new, covering runtime version reporting).
• shellcheck -S style deploy/*.sh — clean.
• The version lookup degrades to "unknown" rather than failing the boot on a host without git, without FFmpeg, or with a hung subprocess. Tested for FileNotFoundError, PermissionError and TimeoutExpired, and asserted that _first_line passes a timeout at all.
• A test asserts the startup line cannot leak DISCORD_TOKEN.

Note for a follow-up

journalctl shows systemd rejecting one line of the live .env:

Ignoring invalid environment assignment '<a URL>': /home/ubuntu/LoopifyBot/.env

Harmless — it is ignored and the bot reads config through python-dotenv anyway — but the file is parsed by two things with different rules, and they can disagree on quoting. Filed separately rather than expanding this PR.