Tell macOS binary users when a newer release is available

Chiusa
  • Qualcosa non va?
#543 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@LJY2000-max ci sta già lavorando.

Dal 29/10/2026.

  • #545 di @LJY2000-max — aperta

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

Problem

A candidate who runs the prebuilt macOS binary from the latest release has no way to learn that a newer build exists. Every successful build of main replaces latest (docs/install.md), several times a day at the current pace, but the running binary never says so. The only way to find out is to open the releases page by hand and compare the commit ./codetrial --version prints with the one the release names, since the package version stays 0.1.0 across builds. In practice that check is skipped, so candidates keep practicing on builds that already have fixes they are missing, and a bug report from such a build describes behavior main no longer has.

docs/desktop.md already lists automatic updates as something the desktop app does not do. This asks for something smaller than updating: telling the candidate that an update exists.

Proposed behavior

The lobby checks whether the latest release names a different commit than the running binary, at three moments:

  1. When the binary starts and the lobby first loads.
  2. When the candidate ends an interview and returns to the lobby.
  3. Every hour on the hour while the lobby stays open and no interview is running.

When a newer build exists, the lobby shows a dialog that names the running commit and the release's commit and links to the release page (or the macOS asset). No check runs and no dialog appears during an interview.

Scope

The CLI binary for macOS (codetrial-aarch64-apple-darwin.zip from latest) only, because macOS is the only platform I can test on. The check itself does not depend on the platform, so Linux, Windows and the desktop app's desktop-latest can follow once someone who can test them picks them up. Downloading or replacing the binary is out of scope: the candidate still replaces the executable by hand, keeping config/, as docs/install.md describes.

Acceptance criteria

  • A macOS release binary older than latest shows the dialog at each of the three moments above, with a working link.
  • A binary that matches latest shows nothing.
  • A failed check (no network, a GitHub error, the short window in which latest resolves to nothing while it is republished) shows nothing and does not affect the lobby or an interview.
  • Nothing is checked or shown while an interview is running.

Implementation notes

The running commit is already known: build.rs embeds the first seven characters of GITHUB_SHA as CODETRIAL_BUILD_COMMIT, and the release job creates latest with --target "$GITHUB_SHA", so the two can be compared directly. Moments 1 and 2 are one code path: leaving an interview navigates to /, so the lobby loads afresh either way.

Two ways to make the check, compared:

  • The server asks GitHub (GET /repos/sysprog21/codetrial/releases/tags/latest) and caches the answer, and the lobby asks the server through a new endpoint. The page's connect-src stays as it is, and one GitHub request per hour serves every open tab, well inside the unauthenticated limit of 60 requests an hour.
  • The lobby asks GitHub directly. This needs https://api.github.com added to connect-src in src/web/policy.rs, and every open tab makes its own requests.

The first keeps the page's policy unchanged, so I would start there.

Questions

  • Should the check be on by default, or opt-in, given that it sends a request to GitHub that the binary does not make today?
  • A build from source has a commit too, but usually not one latest will ever name. Should the check run only in release builds, for example only when GITHUB_SHA was set at build time?
  • After the candidate dismisses the dialog, should it stay hidden until the next release, or appear again at the next check?

Related

#153 (merged) made a binary report the commit it was built from, which is what this compares. #14 (merged) introduced the single rolling latest release this reads. #494 (merged) publishes desktop-latest for the desktop app. I found no existing issue or PR about update notifications.

Lingua principale
Rust
Stelle
215
Fork
141
Merge medio
1g 12h
PR unite (30g)
230

Preparare l'ambiente

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 sysprog21/codetrial

Tutte le issue di sysprog21/codetrial

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.