fix: show file path in textlint CI failures and fix existing violation

[Copilot]

make textlint format=github uses textlint's --format github formatter, which emits GitHub Actions annotations. In the CI log these render as bare error messages with no file context, making failures like Error: Incorrect term: "id", use "ID" instead impossible to locate without digging through annotations.

Change

• Remove format=github from the textlint CI step so the default formatter runs, which prints the full file path, line, and column directly in the log:

/path/to/.chloggen/web_vital-attributes.yaml
  13:69  ✓ error  Incorrect term: "id", use "ID" instead  terminology

• Fixes texlint does not tell where the problem is #3927

[opentelemetry-pr-dashboard]

Pull request dashboard status

Status last refreshed: 2026-07-25 15:08:33 UTC.

• Waiting on: Reviewers
• Next step: Review the latest changes.

This automated status or its linked feedback items may be incorrect. If something looks wrong, please report it with the result you expected.

[lmolkova]

Run make textlint
semantic-conventions@ /home/runner/work/semantic-conventions/semantic-conventions
├─┬ textlint-filter-rule-allowlist@4.0.0
│ └── textlint@15.7.1 deduped
├─┬ textlint-rule-period-in-header@0.1.2
│ └── textlint@15.7.1 deduped
└── textlint@15.7.1


/home/runner/work/semantic-conventions/semantic-conventions/.chloggen/web_vital-attributes.yaml
  13:69  ✓ error  Incorrect term: “id”, use “ID” instead  terminology

✖ 1 problem (1 error, 0 warnings, 0 infos)
✓ 1 fixable problem.
Try to run: $ textlint --fix [file]
make: *** [Makefile:115: textlint] Error 1

[Copilot]

Pull request overview

Updates the textlint CI workflow to make failures easier to debug by ensuring the log output includes file/line/column context (instead of relying on GitHub Actions annotations from the --format github formatter).

Changes:

• Removed format=github from the textlint CI step so make textlint uses textlint’s default formatter (which prints file path + location in logs).

[lmolkova]

@copilot now go fix the violation and update title to say that we fixed it

[Copilot]

@copilot now go fix the violation and update title to say that we fixed it

Fixed the violation in .chloggen/web_vital-attributes.yaml — changed id to ID on line 13. Textlint now passes cleanly. The PR title update is outside my scope here (the title is set at the PR level), but please feel free to update it to something like "fix: show file path in textlint CI failures and fix id→ID terminology violation".

[thompson-tomo]

This actually removes functionality. Currently the filepath is used to report it as an annotation

This enables a reviewer to see directly on a changed file the issues hence is easier then scrolling through logs.

Also the fix is not correct as id represents a field name which is lowercased and not upper, to fix either chang config aka #3929 to ignore the directory or #3930 which uses backticks to indicate it is a field/attribute name.

[lmolkova]

Annotation is not as helpful as ci log, much harder to see regardless is you're a human or an agent. It's nice to have, but not at a cost of not having filename in the plain text.

Especially problematic when error is on the file that's not in the PR - current problem.

[thompson-tomo]

Current problem is an edge case which only occurs during merge process and files changing before merge.

I am not following how it is harder on humans for issues going forward as for everyone reviewing the files via the changes tab can see issues on the file inline that way they have max context. They can also see them at the top of the check which is where they go to get their logs.

It should be easier for agents as now the check itself provides a list of errors & their location.

[lmolkova]

Edge case maybe, it's not the last time it happens - textlint will get new rules and they'll fail in random places.

There literally no information when it does on where the problem is

I'm going to repeat that path on log is a must, github comment is nice to have. Going through all github comments is much harder than looking into ci logs.

[thompson-tomo]

It's right there in the annotations section at the top of the screen. Annotations are similar to comments but are different.

Also all rules are implemented as npm packages so we need to explicitly enable the additional npm package we have added to our project for it to result in a difference in behaviour.

[lmolkova]

It's wonderful to see annotations.
It's not wonderful that they show up collapsed - that's probably why I never look at them. Thanks for educating me they show up there.
It's not acceptable that they turn off file locations in the CI logs.

---

yamllint for example, does it well: https://github.com/open-telemetry/semantic-conventions/actions/runs/29971521674/job/89094348620?pr=3919

annotations and CI logs are not mutually exclusive. If textlint does it right, I'll be happy to enable github format.