Skip to content

Release v3.35.1 - #216

Merged
atomantic merged 5 commits into
releasefrom
main
Aug 27, 2026
Merged

Release v3.35.1#216
atomantic merged 5 commits into
releasefrom
main

Conversation

@atomantic

Copy link
Copy Markdown
Owner

Summary

Patch release fixing /do:next's GitLab issue-claiming path.

  • glab api (unlike the glab issue / glab mr subcommands) has no built-in --jq flag and exits with Unknown flag: --jq. All four glab api call sites in commands/do/next.md now pipe to the standalone jq binary instead.
  • Caught live while dogfooding against a real GitLab issue (fix: glab api has no --jq flag, pipe to jq instead #215).

Test plan

  • npm test — 397 tests pass, 0 fail
  • Grepped the tree: no glab api … --jq occurrences remain outside changelog prose
  • glab issue view --jq deliberately left alone (that subcommand does support the flag)

Full Diff: v3.35.0...v3.35.1

atomantic and others added 5 commits August 27, 2026 09:00
Caught live while dogfooding the fix against a real GitLab issue: plain
glab api (unlike glab issue/glab mr subcommands) has no built-in --jq
flag and errors with "Unknown flag: --jq." Every glab api call now pipes
to the standalone jq binary instead.
`glab api user | jq -r .username` reports only jq's exit status, and jq -r
exits 0 on empty input, so a failed `glab api` left ME empty: --self's
--author filter silently matched everything, and the claim marker assigned
nobody while still looking like it succeeded. Both sites now capture glab's
status separately and use `jq -er`.

Also probe for jq in the GitLab pre-flight — piping to the standalone binary
made it a hard dependency of that path, which only glab was being checked for.
…e jq probe

Two follow-ups from the second review pass:

- `jq -e` fails only on null/false, so `{"username":""}` exited 0 and left ME
  empty. `--author ""` is not an empty filter to glab, it is NO filter — --self
  would have enumerated and claimed other people's issues. Both sites now guard
  on non-empty separately from the -e check.
- The jq probe was in the shared pre-flight, so a GitLab repo working a PLAN.md
  backlog aborted without jq even though that mode never calls plain `glab api`.
  Moved it to the top of Phase 1 issues mode, where the dependency actually is.
A links-API outage read as "no native blockers" because the pipeline reported
jq's status and jq succeeds on empty input — so the picker could claim a
dependent ahead of its blocker. The lookup now captures glab's response and
status first; a failed lookup is UNRESOLVED (body convention only, stated
aloud), not unblocked.

Also probe for jq in the swarm preconditions: swarm replaces Phases 1-7, so
Phase 1's probe never ran there even though A1e/A2e make the same
`glab api ... | jq` dependency call.
@atomantic
atomantic merged commit 5704aa1 into release Aug 27, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant