Noah
6c06b85b1c
* feat(cli): let serve run on a host-bound listener with a host-owned shutdown ServeOptions gains two optional fields for embedding hosts: - listener: serve on an already-bound socket, so the host knows the actual port (e.g. after falling back to port 0); - shutdown: stop when the given future completes instead of installing Ctrl+C / SIGTERM handlers, which would otherwise take those signals away from the host process. The CLI path is unchanged apart from binding the port before opening the database, so a busy port now fails before data/ is touched. Ref #1721 * feat(desktop): run biliup server in-process, drop PyInstaller sidecar The Tauri app now depends on biliup-cli as a library and runs entry::serve on its own tokio runtime instead of spawning binaries/biliup.exe: - listens on 127.0.0.1:19159, or a free port when that one is taken; the window shows a bundled startup page and switches to the Web UI once GET / answers 200 (startup failures are shown on that page); - data/, ds_update.log, cookies.json and recordings live in app_data_dir(); on first start, data/ left in the install directory by the old sidecar is copied over and the original is kept; - closing the window stops the server and waits for it (up to 10 s); no expect() on exit; - a second launch focuses the running window instead of starting a second server on the same data. Removed: the greet command, the Vite + React scaffold under tauri-app/src, the shell:allow-execute capability, tauri-plugin-shell, tauri-plugin-opener, GBK decoding of sidecar stdout and the bundled binaries/ resource. The Web UI itself is unchanged. Ref #1721 * ci(desktop): build the Tauri app directly, remove biliup.spec The Windows desktop workflow no longer builds a wheel, installs it and runs PyInstaller: it builds the Web UI (embedded into biliup-cli by rust-embed) and then the Tauri app with tauri-action. Renamed pyinstaller-publish.yml to desktop-publish.yml. On release it uploads to the release as before; a manual workflow_dispatch run only builds and uploads the installers as an artifact, without touching any release. The Dockerfile used biliup.spec to tell whether it was built from a checkout (otherwise it clones master); it now checks pyproject.toml. Ref #1721 * ci(desktop): smoke-test the installer on manual runs Only on workflow_dispatch: pretend an old install left data/ in the install directory, install the NSIS package silently, start the app and require GET http://127.0.0.1:19159/ to return 200, the database to be created in the app data directory, the old data/ to be copied there and kept in place, and the server to stop when the window is closed. Ref #1721 * feat(desktop): keep data next to the exe unless it is on the system drive On Windows the data directory is the install directory again, as with the old sidecar, when the executable is not on %SystemDrive%. When it is, the first start asks the user (tauri-plugin-dialog): the app data directory (default), the install directory, or another folder. The choice is saved as {"data_dir": ...} in desktop.json under the app config directory and not asked again; a saved directory that cannot be used is reported on the startup page instead of silently creating a new one. Closing the dialog quits. Other platforms have no drive letters and install into read-only locations, so they keep using the app data directory (or data_dir from desktop.json) without asking. When the chosen directory has no data/ yet, data/ left by an older version is copied there and kept in place. Besides the install directory, Windows also looks where the old bbup-app installers put the app (their registry keys and %LOCALAPPDATA%\bbup-app), since a new product name installs into a new directory. The data directory is resolved on a separate thread because the dialog blocks. The migration helpers move to data_dir.rs unchanged. Ref #1721 * chore(desktop): replace the template names with biliup - productName bbup-app -> biliup (installers biliup_<version>_x64-setup.exe and biliup_<version>_x64_en-US.msi, NSIS default install directory %LOCALAPPDATA%\biliup, Start menu entry biliup) - identifier com.tauri-app.app -> com.biliup.desktop (app data directory %APPDATA%\com.biliup.desktop, which is the default data directory offered on the system drive) - Cargo package tauri-app -> biliup-desktop (executable biliup-desktop.exe, so it is not confused with the biliup CLI), lib tauri_app_lib -> biliup_desktop_lib, drop the template authors - npm package name, workflow artifact name and the README download link Tauri derives the NSIS uninstall/registry keys and the MSI upgrade code from the product name, so the new installers do not replace an installed bbup-app; both show up in Apps & features. The app copies data/ from the old bbup-app install directory on first start (see the previous commit), after which bbup-app can be uninstalled; its uninstaller does not delete data/. Ref #1721 * ci(desktop): bump the workflow actions to their latest majors actions/checkout v4 -> v7, actions/setup-node v4 -> v7, actions/upload-artifact v4 -> v7 (Node 24 runtimes; the other breaking changes are about fork checkouts in pull_request_target, caching driven by a packageManager field and single-file uploads, none of which this workflow uses). Swatinem/rust-cache@v2 and dtolnay/rust-toolchain@stable already track the latest release. tauri-apps/tauri-action v0 -> v1. v1 updates the name and body of an existing published release it finds by tagName with releaseName and releaseBody, which are empty here and would wipe the release notes, so the release job now passes releaseId from the release event instead; with releaseId the action uploads to that release without looking it up. Ref #1721 * ci(desktop): smoke-test the new data directory rules on manual runs Replaces the manual-run smoke step from the earlier smoke-test commit and can be dropped together with it. On the Windows runner: - install the v1.2.8 bbup-app NSIS package into C:\old-bbup-app and leave a data/ there; - install biliup into its default directory on the system drive (with an old data/ in it); both products stay installed side by side; - first start shows the data directory dialog and does not start the server; UI Automation clicks the default button (the dialog text and a screenshot are kept as evidence), then GET / must return 200, the database and the copied data/ must be in %APPDATA%\com.biliup.desktop, the original kept and the choice saved in desktop.json; - a second start must not ask again; a preset desktop.json pointing at another directory stands in for "choose another folder"; - reinstall on D: (or a subst drive when the runner has none): no dialog, database and log in the install directory, data/ copied from the old bbup-app directory found through its registry key; - uninstalling bbup-app keeps its data/. Ref #1721 * Revert "ci(desktop): smoke-test the new data directory rules on manual runs" This reverts commit 860c45e89f8e5dab11468c83db7c623b7304e4dd. * Revert "ci(desktop): smoke-test the installer on manual runs" This reverts commit b3831f014a2b37f81b71c96e8229a6254bee1b9c.
13 lines
194 B
JSON
13 lines
194 B
JSON
{
|
|
"name": "biliup-desktop",
|
|
"private": true,
|
|
"version": "0.1.0",
|
|
"type": "module",
|
|
"scripts": {
|
|
"tauri": "tauri"
|
|
},
|
|
"devDependencies": {
|
|
"@tauri-apps/cli": "^2.11.5"
|
|
}
|
|
}
|