Skip to content
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

Closed
shmuelie opened this issue Oct 1, 2024 · 5 comments
Closed

Azure Pipeline Formatter #426

shmuelie opened this issue Oct 1, 2024 · 5 comments
Labels
question Further information is requested

Comments

@shmuelie
Copy link

shmuelie commented Oct 1, 2024

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

@DavidAnson
Copy link
Owner

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.

igorshubovych/markdownlint-cli#58

@DavidAnson DavidAnson added the question Further information is requested label Oct 2, 2024
@shmuelie
Copy link
Author

shmuelie commented Oct 2, 2024

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.

@DavidAnson
Copy link
Owner

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.

@shmuelie
Copy link
Author

shmuelie commented Oct 2, 2024

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 😅

@DavidAnson
Copy link
Owner

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants