markdownlint-cli2
markdownlint-cli2 copied to clipboard
Azure Pipeline Formatter
Using this in an Azure Pipeline, and while I can have the pipeline show the SARIF result, the errors aren't show as build errors. I would love to have a formatter that logged things for the pipeline to pick up, something like the examples shown in Log a warning about a specific place in a file
The reference you link to describes logging commands as something for a script or a task to use. However, markdownlint-cli2 is neither of those. What I think you want here is something VS Code calls a "problem matcher", though I don't see how to define one of those in a DevOps pipeline.
https://code.visualstudio.com/docs/editor/tasks#_processing-task-output-with-problem-matchers
Please have a look at this related thread which leads me to believe the existing JUnit formatter may already work for your scenario.
https://github.com/igorshubovych/markdownlint-cli/issues/58
I was imagining something like (which I've tested and does work)
const outputFormatter = (options) => {
const { logMessage, results } = options;
for (const errorInfo of results) {
const { fileName, lineNumber, ruleNames, ruleDescription, errorRange } = errorInfo;
const [ ruleId ] = ruleNames;
const column = (errorRange && errorRange[0]) || 0;
logMessage(`##vso[task.logissue type=error;sourcepath=${fileName};linenumber=${lineNumber};columnumber=${column};code=${ruleId}]${ruleDescription}`);
}
};
module.exports = outputFormatter;
While the JUnit formatter would work, it would show the linting as tests which I'm not sure is what I'd want.
Thanks for sharing the above, it's great to know that approach works!
I guess I'm not clear what the goal is here. SARIF seems to work for reporting things as information and JUnit seems to work for reporting them as failures, so what is it about the log message format that is interesting or different?
While your example works for this purpose, the impression I got from the documentation you linked to is that it's intended for bash or PowerShell scripts and not specifically for the output from tools they run.,
That said, I don't think there's harm in doing this as it is optional for users, but it feels like a very narrow use case and I'd like to understand it better.
For the documentation, my understanding is that custom tasks use this logging format, they might just have helper methods that allow them to not use string concatenation to create them.
The thing for me is that:
- SARIF results show in the "scanning" tab, so they're hidden from the user unless they go there
- Using the JUnit trick makes the linting show as test failures, not build failures which is what I want them to show as.
It's admittedly maybe an opinionated way for seeing the output but it's how I see it 😅
@shmuelie, you should be able to try the new output formatter now: https://www.npmjs.com/package/markdownlint-cli2-formatter-template
I included an example using the format you tested and shared above. This formatter will be included with the next release of markdownlint-cli2, so if you find any issues, please let me know ASAP.