barrettruth/ci.nvim
Watch
1
0
Fork
You've already forked ci.nvim
 0
Code Issues Pull requests 1 Releases Packages Activity Actions

fix: stop repeating the run id back at the reader #17

Closed
barrettruth wants to merge 3 commits from fix/run-winbar-title into main
pull from: fix/run-winbar-title
merge into: barrettruth:main
Conversation 0 Commits 3 Files changed 3 +44 -20
barrettruth commented 2026-07-27 23:03:25 +00:00
Owner
Copy link

Checklist

  • I have read CONTRIBUTING.md.
  • No AI was used to generate, edit, or review any part of this contribution.

Problem

bufname  ci://neovim/neovim/run/30311973753
winbar   CI neovim/neovim | 1 skipped, 1/2 passing | run 30311973753

The title segment was the number already in the buffer's name, and nothing
besides. Every other list earns that space — a commit shows its subject, a pull
request its title — but the run paraphrased its own URI.

guh.nvim does repeat ids (PR #%{b:guh.id} against a guh://…/{feat}/{n}
bufname), so duplication alone is not the objection. There the id is one
segment among several that are not in the name. Here it was the whole segment.

Solution

The head SHA and the workflow name were both already fetched — the SHA is used
two lines later to build up — and neither appears in the buffer name:

CI neovim/neovim | 1 skipped, 1/2 passing | e3c5974a  no_response

Same shape as the checks list, which reads e3c5974a feat(dir): open cwd….

The attempt suffix goes too, for the same reason: ci://…/run/{id}/{attempt}
already carries it.

## Checklist - [x] I have read [CONTRIBUTING.md](https://forge.barrettruth.com/barrettruth/ci.nvim/src/branch/main/CONTRIBUTING.md). - [ ] No AI was used to generate, edit, or review any part of this contribution. ## Problem ``` bufname ci://neovim/neovim/run/30311973753 winbar CI neovim/neovim | 1 skipped, 1/2 passing | run 30311973753 ``` The title segment was the number already in the buffer's name, and nothing besides. Every other list earns that space — a commit shows its subject, a pull request its title — but the run paraphrased its own URI. `guh.nvim` does repeat ids (`PR #%{b:guh.id}` against a `guh://…/{feat}/{n}` bufname), so duplication alone is not the objection. There the id is one segment among several that are not in the name. Here it was the whole segment. ## Solution The head SHA and the workflow name were both already fetched — the SHA is used two lines later to build `up` — and neither appears in the buffer name: ``` CI neovim/neovim | 1 skipped, 1/2 passing | e3c5974a no_response ``` Same shape as the checks list, which reads `e3c5974a feat(dir): open cwd…`. The attempt suffix goes too, for the same reason: `ci://…/run/{id}/{attempt}` already carries it.
fix: keep a job's metadata when its log cannot be fetched
All checks were successful
quality / Lint (pull_request) Successful in 6s
Details
quality / Test (pull_request) Successful in 6s
Details
quality / Format (pull_request) Successful in 7s
Details
82fb358f70
 
The job request and the log request run side by side, but everything the
first one returns was being written from a function that waits for both. A
skipped job has no log, so that function bailed and the metadata was dropped
on the floor despite having arrived intact.

The buffer was left knowing nothing about itself: no run to go up to, so "-"
answered "already at the top level"; no html_url, so gX had nowhere to go;
and a winbar reading "LOG neovim/neovim" with no name, conclusion or
workflow. The one case where a reader most needs to be told what happened
was the case that told them least.

The job callback now writes its own fields as soon as they arrive, and the
shared function is left to do only what it needs both halves for, which is
rendering the log.
The message listed the three things it could have been, because it was written
in the transport layer, which sees an HTTP code and nothing else. One layer up
the job has already been fetched and knows.

A 410 is still worth naming on its own, since an expired log says nothing about
the job's conclusion and "no log: job is success" would be a riddle. Everything
else reports the job's own state, so cancelled, neutral and timed_out read
correctly today and whatever GitHub adds next will too, without another branch.

Errors that are neither pass through as gh wrote them, which they did not
before: a 404 test was swallowing them into the same sentence.
fix: stop repeating the run id back at the reader
All checks were successful
quality / Test (pull_request) Successful in 8s
Details
quality / Format (pull_request) Successful in 12s
Details
quality / Lint (pull_request) Successful in 14s
Details
294cf243ba
 
A run buffer's winbar read "run 30311973753", which is the number already in
its name and nothing besides. Every other list earns its keep there: a commit
shows its subject, a pull request its title. This one paraphrased the URI.

The head SHA and the workflow name were both already in hand, and neither is
in the buffer name, so the run reads like its siblings now:

    ci://neovim/neovim/run/30311973753
    CI neovim/neovim | 1 skipped, 1/2 passing | e3c5974a  no_response

The attempt goes with it. It was likewise only ever a restatement of the URI.
barrettruth closed this pull request 2026-07-27 23:11:52 +00:00
All checks were successful
quality / Test (pull_request) Successful in 8s
Required
Details
quality / Format (pull_request) Successful in 12s
Required
Details
quality / Lint (pull_request) Successful in 14s
Required
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
barrettruth/ci.nvim!17
No description provided.