Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Tell macOS binary users when a newer release is available

已关闭
  • 哪里不对？
#543 2 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@LJY2000-max 已经在做这个了。

开始于 2026年10月29日。

  • #545 来自 @LJY2000-max —— 未关闭

评估

这个 Issue 还没有评估数据。

描述

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.

主要语言
Rust
星标
215
派生
141
平均合并
1 天 12 小时
30 天内合并 PR
232

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

sysprog21/codetrial 的其他 Issue

查看 sysprog21/codetrial 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。