Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Tell macOS binary users when a newer release is available

クローズ
  • 何か問題がありますか？
#543 コメント 2 件 リアクション 0 件 担当者 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時間
マージ済み PR（30日）
232

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sysprog21/codetrial のほかの issue

sysprog21/codetrial の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。