ci: update minimal-zig example to Zig 0.16 API#5803
Merged
Conversation
Zig 0.16 removed `addIncludePath`, `addLibraryPath`, `linkSystemLibrary`, and `linkLibC` from `Build.Step.Compile` — they now live on `Module`. Update the minimal-zig example to call these on `exe.root_module` / `unit_tests.root_module`, pass `.link_libc = true` via the module `CreateOptions`, and add the new second argument to `linkSystemLibrary`. With the example fixed, unpin Zig in `test-prqlc-c.yaml` so CI uses the default (latest) version again. Follow-up to #5801. Co-Authored-By: Claude <noreply@anthropic.com>
prql-bot
commented
Apr 15, 2026
Collaborator
Author
prql-bot
left a comment
prql-bot
left a comment
There was a problem hiding this comment.
Duplicate of #5804 — both PRs are self-authored, opened 48s apart, and make the same two changes (move addIncludePath/addLibraryPath/linkSystemLibrary to Module + drop the version: 0.15.2 pin). On #5802 the bot itself announced #5804 as "the follow-up" — so this PR (#5803) should probably be closed as the duplicate. Flagging for a maintainer to pick one.
The code here is correct — Module.CreateOptions.link_libc: ?bool and Module.linkSystemLibrary(name, options) match the Zig 0.16 API, and keeping installHeader on Compile is right.
Difference from #5804 worth noting when choosing: #5803 keeps the module inlined inside b.addExecutable(.{...}) and configures it via exe.root_module.xxx(); #5804 hoists the module into a named const exe_mod and configures it before passing to b.addExecutable. Functionally identical; #5804's shape is slightly more conventional for Zig 0.15+.
tend-agent
pushed a commit
to max-sixty/tend
that referenced
this pull request
Apr 15, 2026
Two tend-mention runs on PRQL/prql fired concurrently (issue #5802 and PR #5801) and each opened a near-duplicate PR for the same Zig 0.16 build.zig migration — PRQL/prql#5803 and PRQL/prql#5804, created 48s apart. Both runs ran `gh pr list` at session start (before either PR existed) and neither re-checked before `gh pr create` ~7 minutes later, so each thought the other's PR didn't exist. tend-mention's concurrency group is keyed by issue/PR number, so mentions on different threads are not serialized. Add a dedup recheck step in the PR Creation section analogous to the existing dedup check for inline review comment replies — re-run `gh pr list` immediately before `gh pr create`, and compare by title keywords and modified file paths (not just branch name, which two concurrent runs will pick differently). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This was referenced Apr 15, 2026
max-sixty
pushed a commit
to max-sixty/tend
that referenced
this pull request
Apr 15, 2026
## Summary Add a dedup recheck step in `running-in-ci` for PR creation, analogous to the existing dedup check for inline review comment replies. Re-run `gh pr list` immediately before `gh pr create` so a concurrent sibling run doesn't slip a duplicate PR past the initial session-start check. ## Evidence Observed on `PRQL/prql` in runs [24464554439](https://github.com/PRQL/prql/actions/runs/24464554439) and [24464634498](https://github.com/PRQL/prql/actions/runs/24464634498). Timeline: - 15:57:00 — `max-sixty` commented "do the follow-up please" on issue [PRQL/prql#5802](PRQL/prql#5802) (Zig 0.16 follow-up) - 15:57:03 — `tend-mention` run A started on issue #5802 - 15:58:45 — `vanillajonathan` commented on PR [PRQL/prql#5801](PRQL/prql#5801) asking the bot to create a Zig 0.16 PR - 15:58:48 — `tend-mention` run B started on PR #5801 (different concurrency group — runs in parallel with A) - ~16:02 — each run calls `gh pr list` once, early in its session; no Zig fix PR exists yet - 16:08:17 — run B calls `gh pr create` → [PRQL/prql#5803](PRQL/prql#5803) - 16:09:05 — run A calls `gh pr create` → [PRQL/prql#5804](PRQL/prql#5804), 48s after #5803 appeared; no recheck Both PRs modify the same two files (`.github/workflows/test-prqlc-c.yaml` to drop the `version: 0.15.2` pin, and `prqlc/bindings/prqlc-c/examples/minimal-zig/build.zig` to move calls onto `root_module`) with the same intent — near-duplicates differing only in refactoring style. Maintainers must now triage and close one. ## Root cause `tend-mention`'s [`handle` job concurrency group](https://github.com/max-sixty/tend/blob/main/generator/src/tend/workflows.py) is keyed by `issue.number || pull_request.number`, so mentions on different threads (issue #5802 vs PR #5801) run concurrently. The current `PR Creation` guidance says to check `gh pr list` before creating, but in practice runs do this once at session start. Minutes pass between the check and `gh pr create`, during which a sibling run can open a scope-overlapping PR — invisible to the stale check. ## Gate assessment - **Confidence**: High — concrete wrong outcome (two open PRs for the same fix) with a traced decision chain for both runs. - **Structural vs stochastic**: **Structural**. The same conditions (two mentions on different threads asking for the same fix within a few minutes) will reliably reproduce this; the current guidance prescribes a one-shot check that the race outflanks. - **Occurrences**: 1 this run, 0 historical in [#133](#133). Passes Gate 1 under the "one clear occurrence sufficient for structural failures" rule. - **Magnitude**: Targeted fix — adds a 17-line recheck section analogous to the existing `Dedup check for inline review comment replies` pattern merged in [#141](#141). Passes Gate 2. ## Test plan - [ ] Skill lint (`pre-commit run --all-files`) - [ ] Verify the proposed `gh pr list --state open --author $BOT_LOGIN --json number,title,headRefName,createdAt` returns what a bot can actually use to decide (it does: standard gh flags) - [ ] Spot-check: the next time two concurrent mentions hit different threads asking for the same fix, only one PR should be created Co-authored-by: continuous-bot <269947486+continuous-bot@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This was referenced Apr 16, 2026
Closed
3 tasks
max-sixty
pushed a commit
to max-sixty/tend
that referenced
this pull request
Apr 16, 2026
…ed (#290) ## Summary The nightly Step 3 rule defaults to leaving resolved issues open for a maintainer unless the repo's `running-tend` skill explicitly authorizes closing. That default causes the bot to leave *its own* tracking issues open indefinitely after the tracked condition resolves. Adds a narrow carve-out: the bot may `gh issue close` an issue it opened itself to report a transient condition (e.g. a "Nightly tests failed" report), once the fix PR is merged and the relevant CI on `main` is passing. Issues whose body contains "do not close manually" (monthly review-runs / review-reviewers trackers) are explicitly excluded. ## Evidence - **Run**: [PRQL/prql run 24499795330](https://github.com/PRQL/prql/actions/runs/24499795330) (tend-review-runs, 2026-04-16T08:19Z) - **Incident thread**: [PRQL/prql#5802](PRQL/prql#5802) — bot opened "Nightly tests failed", opened fixes [#5801](PRQL/prql#5801) and [#5803](PRQL/prql#5803), both merged, main CI went green, bot commented "Leaving open for a maintainer to close" - **Maintainer pushback**: max-sixty: *"@prql-bot you should close these when things pass"* and then *"presumably we need to add this to the tend skill?"* - **Bot's own diagnosis** (posted as a diff in issue #5802): proposed to authorize closures in PRQL's local `running-tend` skill; the tend-level default was the actual structural gap ## Gate assessment - **Evidence level**: Critical — direct maintainer correction on a bot behavior - **Classification**: Structural — the nightly skill's Step 3 explicitly instructed "leave it open for a maintainer to close" in every case not covered by `running-tend`; same conditions → same outcome every run - **Change type**: Targeted fix — one carve-out paragraph added, existing default preserved for user-reported issues - **Occurrences**: 1 direct this window; prior tracking on #133 documented one *inverse* case (closing a tracking issue with "do not close manually"), which this carve-out explicitly guards against by excluding that marker Both gates pass. The carve-out is intentionally narrow so the #155 / #158 policy (no unauthorized closures on user-reported issues) stays intact. ## Test plan - [ ] Nightly run on a repo without `running-tend` close-authorization where the bot has an open self-opened "X failed" issue with the fix merged → bot closes the issue with a short comment citing the fix - [ ] Same flow but issue body says "do not close manually" (e.g. review-runs tracker) → bot still leaves it open - [ ] User-reported issue (non-bot author) resolved by recent commits on a repo without close authorization → bot comments with evidence, does **not** close (unchanged behavior) --------- Co-authored-by: tend-agent <tend-agent@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>
1 task
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
2 participants
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
Follow-up to #5801 (which pinned Zig to 0.15.2 to unblock CI). This PR updates
minimal-zig/build.zigto the Zig 0.16 API and unpins the Zig version in CI so we track the latest release again.What changed in Zig 0.16
addIncludePath,addLibraryPath,linkSystemLibrary, andlinkLibCwere removed fromBuild.Step.Compileand now live onModule(the field accessible asexe.root_module).linkSystemLibraryalso gained a requiredoptionssecond argument. libc linking is now alink_libc: ?boolfield on the module rather than a method call.Changes
prqlc/bindings/prqlc-c/examples/minimal-zig/build.zig: movedaddIncludePath/addLibraryPath/linkSystemLibrarycalls ontoexe.root_module/unit_tests.root_module; set.link_libc = truein the module'sCreateOptions; added.{}as the new second arg tolinkSystemLibrary.installHeaderstays onCompile(still its home in 0.16)..github/workflows/test-prqlc-c.yaml: removed theversion: 0.15.2pin frommlugg/setup-zig@v2.Test plan
zig buildnow parsesbuild.zigand proceeds into the compile step (the build graph is fully accepted; the only failure was from linking against a dummy stand-in forlibprqlc_c.a).test-prqlc-c / test-ccheck exercises the full path with the reallibprqlc_c.a.