Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Tell macOS binary users when a newer release is available

Đã đóng
  • Có gì không ổn?
#543 2 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@LJY2000-max đang làm issue này rồi.

Từ ngày 29/10/2026.

  • #545 của @LJY2000-max — đang mở

Đánh giá

Issue này chưa được đánh giá.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
215
Fork
141
Merge trung bình
1 ngày 12 giờ
Pull request đã merge (30 ngày)
230

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của sysprog21/codetrial

Tất cả issue của sysprog21/codetrial

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.