ci: pin xlings to 0.4.3 and simplify install step#43
Merged
Sunrisepeak merged 1 commit intomainfrom Apr 25, 2026
Merged
Conversation
- Pin xlings to v0.4.3 by downloading the release tarball directly (the curl|bash installer always fetches the latest release and has no version-pinning env var; this avoids surprise version drift on re-runs) - Drop XLINGS_NON_INTERACTIVE=1: current xlings-install.sh already has TTY-aware fallback (XLINGS_NON_INTERACTIVE / -e /dev/tty / default branches), so the env var is redundant for CI - Switch from `echo PATH=... >> $GITHUB_ENV` to `echo ... >> $GITHUB_PATH` for idiomatic PATH propagation across job steps - Move XLINGS_VERSION to job-level env block alongside MDBOOK_VERSION for centralised version management Tarball URL is verified (200 OK on the linux-x86_64 asset of v0.4.3, released 2026-04-25). Net diff: -3 / +5 lines.
7 tasks
Sunrisepeak
added a commit
that referenced
this pull request
Apr 25, 2026
…cpp11 (#44) Adds a `solutions/` mirror of `dslings/` containing canonical, fully-compilable reference answers — one per cpp11 exercise — and wires up a CI workflow that goes through the same `xmake d2x-buildtools` plugin path that `d2x checker` uses internally to build and run every reference target. ## Why Exercise files under `dslings/` are intentionally broken (D2X_YOUR_ANSWER placeholders, deliberate compile/runtime bugs) so students can fix them. That made it impossible to have a build CI that catches infrastructure drift — e.g. issue #37 where `dslings/en/cpp11/xmake.lua` had silently lost `set_languages("c++17")` for the literal-type-0 target. Reference solutions solve this by giving CI a known-passing endpoint per exercise: - Any drift in xmake target / include paths / language standard surfaces as a build failure - Any teaching mistake (the canonical answer can't actually pass its own d2x_assert checks) surfaces as a runtime failure - Future zh ↔ en drift gets flagged early ## What's in this PR - `solutions/cpp11/<NN>-<feat>-<K>.cpp` — 47 reference answers (one per practice file). Each is the practice file with all D2X_YOUR_ANSWER replaced, all intentional bugs fixed, and `D2X_WAIT` removed. All `D2X_DONT_DELETE_THIS(x)` calls and `d2x_assert*` checks are preserved byte-for-byte from the practice version. - `solutions/cpp11/xmake.lua` — mirrors `dslings/cpp11/xmake.lua` with each target carrying a `-ref` suffix to coexist with the practice targets (e.g. `cpp11-13-long-long-0` and `cpp11-13-long-long-0-ref`). Per-target flag overrides (`-fno-elide-constructors`, `-Wpedantic -Werror`, `set_languages("c++17")`) are mirrored. - `solutions/xmake.lua` — top-level loader that pulls in cpp11 (other chapters can be added later). - `xmake.lua` — one-line addition: `includes("solutions/xmake.lua")`. - `.github/workflows/dslings-ref-ci.yml` — runs on push/PR/dispatch when any of `dslings/`, `solutions/`, `d2x/`, `xmake.lua` change. Installs pinned xlings 0.4.3 (matching the online-ebook workflow) + xmake, then: 1. Lists every `*-ref` target via `xmake d2x-buildtools --command=list` 2. Builds each via `xmake d2x-buildtools --command=build` 3. Runs each and asserts no `❌` and no stray D2X_WAIT 4. Lints that every dslings .cpp has a paired solutions/ counterpart (warning during bring-up; can tighten to error later) The workflow uses the same plugin entry point (`d2x/buildtools/xmake/main.lua`) that `d2x checker` uses internally, so a green CI run is what a student would see locally if they ran `d2x checker cpp11-XX-feat-K-ref` on every solution. ## Local verification Clean rebuild + full sweep of all 47 reference targets via the d2x-buildtools path, on a clean cache: PASS: 47 / 47 FAIL: 0 Verified that: - Existing dslings practice files still produce their intentional teaching errors (didn't accidentally break the student experience). - Asserts in solutions are byte-identical to dslings (no expected-value fudging — checked with `diff` on assert/D2X_DONT_DELETE_THIS lines). - Negative tests: a deliberately wrong solution produces ❌ and CI exits 1; a stray D2X_WAIT triggers the residue check and CI exits 1. ## Notes & follow-ups - cpp14 / cpp17 / cpp20 / cpp23 will follow as those chapters get filled in. The `solutions/xmake.lua` only includes cpp11 right now. - The new workflow file is the second consumer of pinned xlings 0.4.3 (after PR #43's online-ebook update). If we end up with 3+ workflows using the same install snippet, worth extracting it into a composite action. - The `solutions ↔ dslings filename parity` step is a soft warning during bring-up. Once cpp11 stays at 100% coverage for a release cycle, flip it to an error so missing solutions block merges.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
curl … | bashalways pulls the latest release, which means a re-run on a different day can silently change the toolchain. With version pinning, the workflow is reproducible.XLINGS_NON_INTERACTIVE=1: the currentxlings-install.shalready has a 3-branch TTY fallback (XLINGS_NON_INTERACTIVEset //dev/ttyreadable / default no-tty path), so the env var is redundant.GITHUB_ENV→GITHUB_PATHfor idiomatic PATH propagation across steps.XLINGS_VERSIONto job-level env next toMDBOOK_VERSIONfor centralised version management.Net diff: +5 / -3 lines.
Why this also closes the historical "Install mdBook by Xlings" failures
Several historical runs (2025-08-27, 2026-02-02, 2026-02-03, 2026-03-15) failed at this step with
bash: line 152: /dev/tty: No such device or addressbecause earlierxlings-install.shalways tried to read/dev/tty, which doesn't exist on GitHub Actions runners. The current upstream script has TTY-aware fallback, and pinning the xlings version means we get a known-good script every run.Test plan
https://github.com/d2learn/xlings/releases/download/v0.4.3/xlings-0.4.3-linux-x86_64.tar.gzreturns HTTP 200.xlings-0.4.3-linux-x86_64/bin/xlings(matches the workflow's hardcoded path).python -c "import yaml; yaml.safe_load(...)").Install Xlings 0.4.3step succeeds andxlings install mdbook@0.4.43 -yfinds the binary on$PATH.Notes
The workflow currently only triggers on
book/src/**changes, so this PR's merge alone won't run it. Useworkflow_dispatchto verify.