[thompson-tomo]

This groups the logs based on file just like the stylish formatter. This is so that when using the github format you can see what the messages refer to without needing to check annotation.

The current scenario is

[azu]

Where can I find a reference for this format?

[thompson-tomo]

@azu this is logging the file context as plain text so u can see it in the gh logs.

The content going in annotations is defined in https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-commands#setting-a-warning-message

[thompson-tomo]

@azu can u take a look at this please. See open-telemetry/semantic-conventions#3928 as an example of what prompted this usability improvement. Key thing is if the log line starts with :: it triggers handling as an annotation otherwise handles it as an ordinary log line.

[azu]

Thanks, I understand the motivation.
However, the problem is that this is a proprietary format, which is a concern for me.

There are similar reports in Ruff #1693 and Oxlint #20492.

Ruff considered separate plaintext lines, but ultimately included the location in the annotation message itself(Ruff #1696).
Oxlint proposed the same approach in oxc-project/oxc#20499, although that PR was not merged.

For that reason, I would prefer not to add a separate, foo.js: line=5, col=10 line. If we want to work around the GitHub log display limitation, could we include foo.js:5:10 in the annotation message body instead?

::error file=foo.js,line=5,col=10,...,title=foo.js:5:10 Unexpected foo.

Essentially, I think this is a problem that GitHub should fix.
If you're looking for a workaround, I think it's better to include it in the message body, even if it doesn't look as good, because the amount of information will be the same for both the CI log and the annotation, ensuring consistency.

[thompson-tomo]

It seems like there is no consensus on how best to do it, as some widely popular tools ie cspell duplicate the entire log once in standard log format & once in gh format, some group them based on file ie yamlint, some duplicate info into the body ie mdling.

Would it be fine to follow the grouping solution as we already do in the stylish formatter? That seems the nicest option as it even improves usability as the messages can be collapsed per file.

[azu]

I think <filepath>:<line number>:<column> is better.
For example, browser stack traces and web technologies like VSCode often use this format.

<filepath>:<line number>:<column>: <message>

or

<message> @ <filepath>:<line number>:<column>

Since the location information is displayed in a different location when there are multiple lines, I think the following format, similar to Ruff, would be better.

<filepath>:<line number>:<column>: <message>

[thompson-tomo]

Filepath is un-necessary as it is the name of the group and this follows the structure of the stylish formatter. These groups provide indentation and even enable collapsible groups of logs hence improves usability.

The location ie L{{x}}C{{x}} is the github format used see https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-a-permanent-link-to-a-code-snippet and also what u get when you share a code reference.

[thompson-tomo]

Also note in pretty view, the user will have a list of files with issues and clicking one shows the issues in that file directly under the heading they clicked. Hence this is a great bonus for a user.

[azu]

The location ie L{{x}}C{{x}} is the github format used see https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-a-permanent-link-to-a-code-snippet and also what u get when you share a code reference.

Hmm, I think it would be fine if it were an actual URL like <url>#L{{x}}C{{x}}.
However, I thought this would just display the string L{{x}}C{{x}}, but am I wrong?
I don't see much value in it because I feel like users would need to understand the meaning of 'L' and 'C'.

Also note in pretty view, the user will have a list of files with issues and clicking one shows the issues in that file directly under the heading they clicked. Hence this is a great bonus for a user.

Do you have a screenshot?

[thompson-tomo]

It would be just like yamllint, see an interactive example at https://github.com/open-telemetry/semantic-conventions/actions/runs/29971521674/job/89094348620?pr=3919

With the logs being

2026-07-23T01:20:10.7416825Z ##[group]./.chloggen/3919.yaml
2026-07-23T01:20:10.7419399Z ##[error]5:1 [empty-lines] too many blank lines (1 > 0)
2026-07-23T01:20:10.7420484Z ##[endgroup]

[azu]

thank you,
The format of yamllint looks good.
How about using the same format?
What I find questionable is the use of the unusual format L<line>C<column> as a string to display.

##[group]<path>
##[error]<line>:<column> [<ruleid>] <message>
##[endgroup]

[thompson-tomo]

I have just added the semicolon between line and column so it is now L<line>:C<column> that way reader has context what it relates to. If you just had 9:40, you could mistake it for a time.

Is that ok, other option would be Location = <line>:<column> but i suspect that is too verbose

[azu]

The context of a file is clear, so I don't think anyone would mistake this for time.

[thompson-tomo]

It's not that clear when you are skim reading things as you are in rush or you have been going at it for a very long time. Anyway i have made the change as even with the ambiguity is still an improvement to what we have now.

[thompson-tomo]

@azu just following up now that i shared additional reasoning why the filename is un-necessary in the body.

[azu]

lgtm