microsoft / infersharp

Infer# is an interprocedural and scalable static code analyzer for C#. Via the capabilities of Facebook's Infer, this tool detects null dereferences, resource leaks, and thread-safety violations. It also performs taint flow tracking to detect critical security vulnerabilities like SQL injections.
MIT License
731 stars 29 forks source link

Visual Studio MarketPlace? #218

Open ncook-hxgn opened 1 year ago

ncook-hxgn commented 1 year ago

I couldn't find you on Visual Studio MarketPlace for Azure DevOps :(

https://marketplace.visualstudio.com/search?term=Infer&target=AzureDevOps

Edit: Found https://github.com/microsoft/infersharp/blob/main/.build/azure-pipelines-example-multistage.yml Pretty cool, but, is an extension likely?

matjin commented 1 year ago

Could you speak more to what your use case for the extension is/how adding Infersharp to Azure pipelines doesn't fully address it?

ncook-hxgn commented 1 year ago

Hi @matjin

An extension providing a task makes it easy for a large organisation like ours to use a tool in a consistent manner across our many pipelines: pipeline maintainers can make use of the Azure DevOps Pipeline Editor's intellisense, and use settings / a wizard to configure the tasks input parameters, which helps avoid mistakes.

A task from an extension also has the advantage that users of the task get minor+patch updates to a tool without needing to write/merge code, and can opt into major updates (potentially breaking changes) by bumping a number on a branch. This is very useful in helping avoid code-rot in our pipelines, especially across a large organisation, and fits neatly into various branching strategies, making pipeline maintenance easier to plan.

This contrasts with the example multistage pipeline linked in the OP, which demonstrates pinning the pipeline to a minor version of the infer# container. Having said this, I admit that with a little work, the example could be refactored to be a template, with a version parameter (a select/radio of known good versions). However, this is a maintenance overhead for me as a devops engineer, so my preferred solution is the extension, if possible.

I'll probably write the template based on the example multistage yaml for now, though :)

matjin commented 1 year ago

OK. Sounds good -- my colleague @xinshiMSFT owns this component -- he's OOF right now but he'll look into this for you when he's back. Thanks for raising this!