Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Ship in-app auto-update with electron-updater

Aperta
  • Qualcosa non va?
#118 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
15/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
github-actions, macos, rust, tauri, typescript
Ambito
desktop, devops, security

Direzione di ricerca

Start with the updater flow in desktop/src/stores/updateStore.ts and the existing configuration in desktop/src-tauri/tauri.conf.json, then trace the release and smoke workflows in release.yml and smoke-test.yml. The issue names the affected UI, Rust portable-mode paths, and tests; read those sections and the linked issue #112 before estimating the platform work. Done means signed update artifacts and latest.json are verified, portable data survives updates, and the About page tests cover the update controls.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

DreamCoder cannot update itself. Users have to notice a new release, download the installer and reinstall by hand.

Most of the updater is already in the tree. It came with the code inherited from cc-haha v0.3.1 and was never switched on:

  • Rust: tauri-plugin-updater and tauri-plugin-process (desktop/src-tauri/Cargo.toml:19-20), registered in lib.rs. prepare_for_update_install (lib.rs:480-491) stops the sidecar before installing, and cancel_update_install undoes it.
  • Permissions: capabilities/default.json already grants updater:default and process:allow-restart.
  • Frontend: desktop/src/stores/updateStore.ts checks 5 s after launch, downloads with progress, prepares, installs and relaunches. components/shared/UpdateChecker.tsx shows the popup and is mounted in AppShell.tsx. Both have tests.
  • Windows installer: the NSIS pre-install hook (windows-installer-hooks.nsh) also stops running sidecars.

What blocks it:

  1. The public key is cc-haha's. plugins.updater.pubkey in tauri.conf.json is the same minisign key (ID 9B9B0D11A79E1F36) as in cc-haha v0.3.1. We don't hold its private key. It must be replaced before any endpoint is added. Otherwise the holder of that private key could sign updates our users would accept.
  2. No endpoint. plugins.updater.endpoints is []. As a result, the check on every launch fails and the error is swallowed (updateStore.ts:173-187).
  3. No update files. release.yml builds with createUpdaterArtifacts:false and uploads only the .dmg and the -setup.exe.
  4. The About page hides it. AboutSettings.tsx:71-75 only shows "updates not available". The strings for "Check now" and "last checked" exist (en.ts:1377-1387) but nothing renders them.

Blocker found along the way: portable mode on macOS

When portable mode is chosen without picking a folder, data goes next to the executable (lib.rs:316-321, main.rs:31-34). On macOS that is inside DreamCoder.app/Contents/MacOS/. The macOS updater replaces the whole .app, so this data would be deleted on the first update. On Windows it sits in the install folder. Whether it survives an NSIS update needs a test.

This has to be fixed before the updater ships. One option is never storing data inside the bundle on macOS. The other is refusing to update while in portable mode.

Design

Signing:

  • Generate our own key with bun x tauri signer generate.
  • Store the private key and its password as GitHub secrets (TAURI_SIGNING_PRIVATE_KEY, TAURI_SIGNING_PRIVATE_KEY_PASSWORD). Keep an offline backup: if the key is lost, existing installs can no longer be updated.
  • Put the public key in tauri.conf.json.

This is separate from Apple or Windows code signing. The updater checks only this signature, so it works with the current ad-hoc signed and unsigned builds.

Endpoint: https://github.com/GoDiao/dreamcoder/releases/latest/download/latest.json. /releases/latest/ skips drafts and pre-releases, so a release reaches users only once it is published.

Release workflow:

  • Tag builds pass the signing secrets and drop createUpdaterArtifacts:false. Pull-request builds keep the override, because fork PRs get no secrets.
  • Upload the update files as well:
    • macOS: DreamCoder.app.tar.gz and its .sig.
    • Windows: the -setup.exe, which doubles as the update file, and its .sig.
  • A new job runs after smoke and writes latest.json with jq. It contains the version, the notes from the CHANGELOG section (without the install instructions), the date, and the URL and signature text for darwin-aarch64 and windows-x86_64. The job uploads latest.json to the draft.
  • Tags containing - (for example v0.6.0-beta.1) are created as pre-releases, so /latest/ never offers them.
  • Publishing stays manual, as today.

Smoke test:

  • Check that both .sig files exist and verify against the public key.
  • On macOS, unpack the .tar.gz and run the same codesign and allow-jit checks as for the .dmg. The sidecar must keep the JIT entitlement after an update (see #112).

App:

  • Keep the silent check on launch and the popup.
  • Restore an "App updates" section on the About page: current version, "Check now", last checked time, "Update now" with progress.
  • Update desktop/src/__tests__/generalSettings.test.tsx:1318-1330.
  • updateStore also has an update proxy setting with no UI (settingsStore.ts:356-362). Either give it a field or remove it.

Platform notes

macOS:

  • The app downloads the update itself, so no quarantine flag is expected and Gatekeeper should not prompt again. To verify on a real machine.
  • Each ad-hoc build has a different code hash. Privacy permissions (Files & Folders, Automation) or keychain access may be asked for again after an update. To verify.

Windows:

  • Default per-user install in %LOCALAPPDATA%\DreamCoder, so no admin prompt. installMode: "passive" shows a small progress window.
  • update.install() starts the installer and exits the app. The installer starts the app again itself, so the "restarting" state never shows on Windows.

Data: the updater never touches ~/.dreamcoder. Storage migrations run on every server start based on file schema, not app version (persistentStorageMigrations.ts), so upgrading is safe.

Plan

One PR:

  1. Fix portable mode on macOS.
  2. New key and endpoint in tauri.conf.json.
  3. release.yml: signing, update files, pre-release tags, the latest.json job.
  4. smoke-test.yml: signature and entitlement checks for the update files.
  5. About page update section and tests.
  6. CHANGELOG, and a line in the release notes that later updates arrive in the app.

The maintainer has to generate the key and add the two secrets. That step can't be done from a PR.

Verification

  • CI: the smoke test checks above, and latest.json validated with jq: version equals the tag, both platforms present, URLs point at assets on the release.
  • Manual, on macOS: install the release before the updater one, then update to a test release through the app. Check that sessions, settings and the sidecar (/api/status version) are fine afterwards. Repeat in portable mode.
  • Windows needs community verification, as in #114.

Costs

  • The first release with the updater can't arrive through the app: users on v0.5.0 install it by hand once.
  • Losing the private key means users have to reinstall manually.
  • macOS may ask for permissions again after each update until we have a Developer ID.

Open questions

  • Publish manually after smoke (proposed), or publish automatically once smoke passes?
  • A beta channel now, or later?
  • Portable mode on macOS: move the data out of the bundle, or refuse to update?
  • Add Intel macOS to the build matrix?
Lingua principale
TypeScript
Stelle
490
Fork
47
Merge medio
9h 38m
PR unite (30g)
75

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di GoDiao/dreamcoder

Tutte le issue di GoDiao/dreamcoder

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.