-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Azure Pipeline Formatter #426
Comments
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. |
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:
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. |
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 text was updated successfully, but these errors were encountered: