mirror of
https://github.com/Evil0ctal/Douyin_TikTok_Download_API.git
synced 2026-10-29 12:59:49 +08:00
Evil0ctal
6d053c2b66
The CloakBrowser commit lives in one place now: docker/compose.yml's default, which moves with the checkout together with the Playwright pins in docker/browser_rpc/requirements.txt (a verified-with line, held equal by a hygiene test). The installer no longer writes it into .env, and an upgrade comments out the two values earlier versions wrote there. A frozen copy is how an install kept 0.5.10 after the requirements had moved to Playwright 1.64. Installs and upgrades follow releases, not main: - A fresh install clones main and checks out the latest release's tag, and pins DTK_IMAGE_TAG to that version instead of `latest`. DTK_VERSION picks another (5.1.6, 5.1, latest, sha-<commit>); DTK_REPO_URL a mirror. - An upgrade checks out the target's tag and hands over to that tag's installer. Then: compose's own config check, pull, browser build, a backup (--no-backup skips it), migrations, and only then the pin and the restart. Anything that fails before the restart, Ctrl-C included, puts the checkout and .env back. A release that lacks the database's migration is refused before anything is pulled. "Already on" needs the running version, .env and the checkout to agree. dtkctl is rewritten only when it has no upgrade command, so edits to its compose line survive. - The v4 branch's V4.x releases are never taken for the latest. No python3 is needed for detection, the release check or version comparison. Fresh installs on more machines: ceilings come from what Docker can use (the VM on Docker Desktop), memswap_limit follows mem_limit (4.6-7.6 GiB hosts failed to start), no service asks for more CPUs than exist (1-CPU hosts died at the first migration), Redis' maxmemory stays under its ceiling, and an edited compose.host.yml is kept as .old. An existing install is found from container labels, also under --yes and DTK_INSTALL_DIR; volumes of the same project without its .env stop a new install that could not open them. Presets are validated and taken out of the environment, Ctrl-C stops the script, and the model download no longer runs chmod -R on what was typed. The menu: Stop keeps the containers, Back returns, removal stops when `down -v` fails, restore takes a name from the list and says it fills in rather than rolls back, settings list in full and set over stdin, logs show every service, restart applies .env, free disk only offers this install's images, transcription goes back off when it does not come up, and an empty password cancels. An install found without being named - the checkout the script is in, the directory it runs from, the default one, Docker's labels - has to be a checkout of this project whose dtkctl belongs to the user or root and is writable by nobody else; a stray file called dtkctl is never run. Piped through curl | bash the script has no directory of its own, and no longer takes the parent of the current one for it. The two installers are compared line by line for code now, not only for control-flow words: a changed number or flag in one used to pass.