Planned Deprecation: GitHub Releases of DevSkim BInaries

[gfs]

We currently publish platform specific binaries of DevSkim to GitHub releases concurrently with publishing to Nuget/VS Marketplace. These releases do not receive much usage, and so we are planning to cease publishing releases in this manner and only publish to Nuget/VS Marketplace.

I am opening this thread for any feedback on these plans.

[JaneX8]

I appreciate the releases on GitHub. Maybe we can use more automation to reduce workload for publishing new releases to multiple platforms. Let me know if I can help.

[gfs]

Thanks for the feedback. It's helpful to know that they are being used. Is there a particular way you use DevSkim that makes the native binaries more convenient than installing via the .NET SDK - or is it just not using the .NET SDK for anything else?

[JaneX8]

The latter. It is useful because I use DevSkim CLI to generate a Sarif file, it's part of a bigger script that does Static Code Analysis with different tools, inside a Linux Docker container. Using the release makes my Dockerfile much simpler, image build time less and image size potentially smaller when less dependencies are needed. I don't use anything else from .NET.

The only suggestion for improvement I can make is adding the architecture to the release filenames for clarity, and perhaps adding support for ARM/AArch, #673. And perhaps #648.

Moreover, from a accessibility and ease-of-use point-of-view the current GH release would in theory make it very easy for package managers such as scoop.sh/chocolatey/homebrew etc, to install and use DevSkim in different environments.

[gfs]

FWIW, its very easy to configure docker with the .NET SDK - including layer on top of the official .NET docker image: https://learn.microsoft.com/en-us/dotnet/architecture/microservices/net-core-net-framework-containers/official-net-docker-images.

For example: https://github.com/microsoft/DevSkim-Action/blob/main/Dockerfile

[JaneX8]

I just started using devcontainers. The whole .NET framework is a big dependency just to install a global tool rather then dropping a platform binary.

However, the only benefit I see is the "package manager" makes it easier to update.

[gfs]

@JaneX8

The difficulty is not really in compiling for additional architectures - it is indeed just a trivial flag to the compiler - but rather in maintaining and supporting the build/signing infrastructure and pipelines for many different distributions. The reality is that we see the vast majority of usage to be on the .NET Tool and the VS Code extension so that is where we have focused our efforts.

A workaround you can use is to use a multi-stage Dockerfile where you'd use the .NET SDK image checkout the DevSkim repo, build it with something like dotnet publish -r linux-arm64 -f net9.0 or dotnet publish -r linux-arm64 -f net9.0 -p:PublishSingleFile=true (ex. to build for linux arm64 native binary you indicate you desire above) and then copy the compiled binary into your slimmer image for actual execution.

For further documentation on docker multi-stage builds: https://docs.docker.com/build/building/multi-stage/.

[JaneX8]

I understand that. I would very much like the DevSkim project to grow in popularity, to grow beyond 1000 Github stars for example. It would likely increase the quality and hopefully people will share their DevSkim rules which will help everyone with the real purpose improved static code analysis, meaning improved code quality.

Therefore keeping those prebuilt binaries easily accessible lowering the bar for anyone who has never used (or simply refuse using) anything .NET and it might scare them away (even though just a few commands). Also releasing prebuilt binaries would allow in the future for people to use their own package manager instead of installing a whole framework (even if lightweight), things like apt install devskim, yum install devskim, scoop install devskim etc and integrate it in their existing workflows.

[janv8000]

Is this deprecation already in effect?
The most recent release https://github.com/microsoft/DevSkim/releases/tag/v1.0.67 contains no downloadable binaries.

Off-topic: regarding the last release with binaries https://github.com/microsoft/DevSkim/releases/tag/v1.0.59 : the DevSkim_CLI_win_1.0.59 does not seem to be a Self-contained app any more but requires the runtime present?

[aetos382]

DevSkim v1.0.70 depends on the .NET 9.0 Runtime.

My machine only has the .NET 10 Runtime installed, and I have no intention of installing 9.0 for DevSkim.

If you are not going to release a runtime-independent package, please release a .NET 10 version as soon as possible.

[JaneX8]

@aetos382 I agree and I think the publishing of signed binaries is actually even more important nowadays. Also makes reliable integration into package managers possible as mentioned here: #644 (comment).