chore: update tend workflows (0.1.20 → 0.1.22) - #6252
Conversation
prql-bot
left a comment
There was a problem hiding this comment.
pre-commit.ci is red on this head, and it won't clear on its own.
actionlint rejects queue: max. The new concurrency.queue key in tend-review.yaml is valid GitHub syntax (docs), but actionlint's schema doesn't know it yet, so the pinned v1.7.12 hook fails the run:
.github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]
Waiting for an autoupdate won't help: v1.7.12 (2026-03-30) is the latest release, rhysd/actionlint#657 and #654 are both open, and the PR that added support (#661) was closed unmerged.
Fix — tend's own repo already hit this and carries the remedy in its .pre-commit-config.yaml; mirroring it here is enough:
- repo: https://github.com/rhysd/actionlint
rev: v1.7.12
hooks:
- id: actionlint
# GitHub accepts concurrency.queue, but this pin does not yet know it.
# Ignore only that schema false positive.
args:
- -ignore
- 'unexpected key "queue" for "concurrency" section'I verified this against actionlint v1.7.12 on the merged tree: the whole .github/workflows/ set exits 0 with the flag and reports only the queue diagnostic without it, so nothing else is being suppressed. .pre-commit-config.yaml is outside this diff, so it needs a commit rather than a suggestion.
Separately, this looks like an upstream gap rather than a PRQL one — the generator emits queue: max into every adopter's workflows, but the -ignore arg only exists in tend's own pre-commit config, so any adopter running the actionlint hook goes red on the next regen. Worth an issue on max-sixty/tend.
Overlaps with #6251. That PR regenerates the same eight tend-*.yaml files to add sandbox_setup: blocks, and those blocks sit in the with: mapping directly under the uses: max-sixty/tend/claude@… line this PR bumps — so the two will conflict. Whichever lands second should be regenerated with uvx tend init rather than hand-merged, particularly since 0.1.22 changes how block prompts are padded (max-sixty/tend#1090), which is exactly the rendering #6251 depends on.
|
Fixed in 8a41d64, and the remedy is broader than the one my review proposed. Two checks were red on this head, not one — The upstream gap is filed as max-sixty/tend#1094 — the generator emits Verification and sourcesAgainst the
MegaLinter's failure was the same single blocking diagnostic — run 33297574559 reports Upstream state, rechecked: v1.7.12 (2026-03-30) is still the latest release; rhysd/actionlint#657 (issue) and #654 (PR) are open; #661 was closed unmerged. My review called #654 an issue — it's a PR. |
Nightly regeneration of the
tend-*workflow files viauvx tend@latest init. Beyond the action-ref bumps, this release reworks thetend-notificationspre-check and removes thetend-reviewHEAD gate — both are inlined shell in the generated workflows, so they show up as real diff rather than a version stamp.tend version: 0.1.20 → 0.1.22
Notable changes
tend-notifications: the pre-check is rewritten around a repository-level recovery queue — it enables repo watching idempotently each cycle, pages the whole unread list at a 10-minute cutoff, and passes that cutoff to the agent, replacing the old layered mark-read sweep (fix(notifications): recover missed work from unread queue max-sixty/tend#1074). The job also gains a serialconcurrencygroup.tend-review: the "Skip when the live HEAD is already examined" gate step is gone. A push mid-review now re-targets the running review instead of letting the queued run exit, and the concurrency group gainsqueue: maxso a push can't evict a pendingready_for_reviewevent (Re-target a review when HEAD moves, instead of discarding it max-sixty/tend#1082, Make Tend review runs less visible max-sixty/tend#1078).review-runsadds a run census as a second input when draining stranded triggers (skills(review-runs): add the run census as a second stranded-trigger drain input max-sixty/tend#1073).watched_workflowsandbranchesare validated as string lists (fix(generator): validate watched_workflows and branches as string lists max-sixty/tend#1076), and block prompts no longer get padded blank lines (fix(generator): stop padding blank lines inside block prompts max-sixty/tend#1090).tend-reviewno longer gates the check poll (fix(scripts): don't let tend-review gate the poll max-sixty/tend#1053).Full upstream diff: max-sixty/tend@0.1.20...0.1.22
Also in this PR: an
.github/actionlint.yamlentry for theconcurrency.queuekey.0.1.22's
tend-review.yamlusesqueue: max, a real GitHub concurrency key that actionlint does not recognise — it fails withunexpected key "queue" for "concurrency" section, turning both MegaLinter and the pre-commit actionlint hook red. Upstream tracks this in rhysd/actionlint#654 and #657; the PR adding support (#661) was closed unmerged, and v1.7.12 — the latest release, and the version pinned in.pre-commit-config.yaml— still rejects it. Without the suppression every future nightly regen lands red, so it ships here rather than as a separate PR that this one would have to wait on.The ignore is scoped to
.github/workflows/tend-*.yamland to that one message. Verified locally with actionlint v1.7.12: the whole workflow directory lints clean with the entry, and adding an unrelated bogus key to the sameconcurrency:block still errors, so the suppression isn't swallowing real problems.