Add update notifications for the prebuilt Windows binary Problem
Maintainer thường phản hồi trong vòng 1 ngày
@Yu-Ming-Chang đang làm issue này rồi.
Từ ngày 29/10/2026.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
Problem
A candidate running the prebuilt Windows binary from the latest release has no way to know that a newer build is available.
Every successful build of main can replace the latest release, but an already downloaded Windows executable continues running the version it was built from. Since the package version remains 0.1.0 across builds, users cannot rely on the package version alone to determine whether their binary is up to date.
Currently, a candidate must manually visit the GitHub Releases page and compare the commit reported by the running binary with the commit associated with the latest release. In practice, this check is easy to overlook.
As a result, Windows users may continue practicing with outdated builds that are missing bug fixes or improvements already available in newer builds. This can also make bug reports more difficult to investigate when the reported behavior no longer matches the latest version.
The existing macOS update notification issue addresses the same problem for macOS users. Windows users should have equivalent functionality for their prebuilt binary.
Proposed behavior
The Windows binary should check whether the latest release identifies a different commit from the running binary at the following moments:
- When the binary starts and the lobby first loads.
- When the candidate ends an interview and returns to the lobby.
- Every hour on the hour while the lobby remains open and no interview is running.
When a newer build is available, the lobby displays a dialog containing:
- The commit of the currently running binary.
- The commit associated with the latest release.
- A working link to the latest release page or the appropriate Windows download asset.
The notification is informational only. The candidate remains responsible for downloading and replacing the executable manually.
No update check should run, and no notification should appear, while an interview is in progress.
If the running binary already matches the latest release, no notification should be displayed.
Scope
This issue covers the prebuilt Windows CLI binary distributed through the latest release:
codetrial-x86_64-pc-windows-msvc.exe
The implementation should reuse the update-checking mechanism introduced for macOS wherever possible. Windows support should not require a separate update service or duplicate the release-checking logic.
The Windows implementation should account for the following:
- Platform-appropriate download link: The notification must not direct Windows users to a macOS-specific archive or executable. Linking to the latest release page is acceptable if a reliable Windows-specific asset URL is not available.
- Manual updates only: Automatically downloading, installing, or replacing the executable is out of scope.
- Configuration preservation: The update instructions should remind users to preserve their existing config/ directory when replacing the executable.
- Release builds: The check should follow the shared implementation's policy for distinguishing official release binaries from builds compiled from source.
- Failure isolation: Update-check failures must not prevent the application from starting or interfere with an active interview.
Linux binaries and the desktop application's desktop-latest release are outside the scope of this issue.
Acceptance criteria
- A Windows binary whose embedded commit differs from the latest release displays an update notification with the running commit, the latest commit, and a working link to the release page.
- A Windows binary that matches the latest release displays no notification.
- If the update check fails, the notification is not displayed, and CodeTrial continues to work normally.
- No update check runs and no notification appears while an interview is in progress.
Implementation notes
The existing build process embeds the first seven characters of GITHUB_SHA as CODETRIAL_BUILD_COMMIT. The release workflow associates the latest release with the commit used to build the release.
These values can be compared directly to determine whether a newer build is available. The package version alone is insufficient because it remains unchanged across builds.
The preferred approach is to reuse the server-side update-checking mechanism proposed in #543:
- The server queries GET /repos/sysprog21/codetrial/releases/tags/latest on the GitHub API.
- The server caches the release information.
- The lobby retrieves the latest commit and release URL through a server endpoint.
- The lobby compares the latest commit with CODETRIAL_BUILD_COMMIT and displays the notification only when they differ.
Reusing this mechanism avoids unnecessary GitHub API requests from individual tabs and avoids adding GitHub's API origin to the page's connect-src policy.
The implementation should follow the shared policy for builds compiled from source that do not correspond to an official release.
Update-check failures must be handled gracefully and must not affect the normal operation of CodeTrial.
Related
#543 — Tell macOS binary users when a newer release is available
#153 — Report the build commit
#14 — Introduce the rolling latest release
Installation documentation
- 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)
- 228
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của sysprog21/codetrial
-
Audio output can be confirmed without playing a test soundCó thể đã có người làm @ChenYingHan1121 đã nhận 11 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
sysprog21/codetrial#359 · 6 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Tell macOS binary users when a newer release is availableCó thể đã có người làm @LJY2000-max đã nhận 1 ngày trước. Đang mở
sysprog21/codetrial#543 · 2 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
An abandoned start holds its interviewer slot for five minutesCó thể đã có người làm @matthiola0 đã nhận 1 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 43/100
sysprog21/codetrial#539 · 3 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Web lobby cannot reopen Setup after configurationCó thể đã có người làm @YEH-YU-YANG đã nhận 2 ngày trước. Đang mở
sysprog21/codetrial#525 · 3 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của sysprog21/codetrial
Issue tương tự
-
good first issue help wanted r-docs
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
servo/rust-smallvec#824 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
Maintainer thường phản hồi trong vòng 1 ngày
-
priority middle
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 62/100
KATO-Hiro/AtCoderClans#12940 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
Maintainer thường phản hồi trong vòng 1 ngày
-
o8 next debug build aborts on Glass to Dark appearance switch (nil identifier messaged before check)Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
hurttlocker/o8#5112 ·