search

mhutch / MonoDevelop.MSBuildEditor

Improved MSBuild editing support
Other
215 stars 26 forks source link

CI/Pipeline EnvVars gets flaged as unused/unknown #168

Open LukasGelke opened 5 months ago

LukasGelke commented 5 months ago

Variables like TF_BUILD (Team Foundation/Azure Devops), and CI (GitHub, GitLab...) and possibly others, are environment variables usually set to true to indicate that the build is running in CI/CD. image

And we also use our own (environment) variables and msbuild-Property-Parameters to get builds to work correctly. In conjunction with the Directory.Build.props. They're intended for them to be distinct from pre-existings Properties (to avoid confusion, conflicts, breaking changes, etc). Creating a json-schema seems a bit overkill for this purpose, but it works. However it seems non-intuitive, if this file needs to be maintained in every repo on it's on (i.e. only copy & paste, no git submodule, or imports or something similar)

mhutch commented 5 months ago

You could technically put this in a sidecar schema for an empty targets/props file in a nuget package, but that seems like overkill here. I'll add some of the more common ones to the built-in schema.

Are there any other properties that you would like treated this way?

mhutch commented 5 months ago

FWIW, I do see a bunch of these as defined when using DotNet.ReproducibleBuilds

image

LukasGelke commented 5 months ago

hm. So if there are builtins, they should obviously be helpful to anybody. But i understand that always updating variables from various CI Docs would be very labor intensive and error prone, once they change then (but in theory realistically the should only add vars, not to break old pipelines).

But also, if there where NuGets for/from each CI system, that be great too, or using something like DotNet.ReproducibleBuilds. But then how would such NuGets influence Directory.Build.props? NuGets only affect projects, and including a props file from a NuGet manually seems like a further extra step.

But I myself am not eager to get a solution soon. If you'd think about it longer or have some plan/ideas like for #169 I'd obviously not be upset to wait. Seems like this here would also better once #94 is implemented?