Please allow direct control over variables that cause arcade to DO something

See: https://github.com/dotnet/arcade/blob/ffc7a871add67b229c7fd41ad1cdff41da926312/src/Microsoft.DotNet.Arcade.Sdk/tools/Publish.proj#L25

All of these variables: PublishToAzure, PublishToSourceBuildStorage, PublishToSymbolServer will not allow me to configure their value since they always explicitly set a value. It would be really useful if I could just control these values, either by injecting a .props file or by making them conditional.

It’s good to have sensible defaults, but I think this logic is much too smart for its own good. Issues that I’m currently trying to solve:

1. I need both symbol publishing and BAR publishing, which requires an extra build step because I can’t configure these things directly.
2. I want to disable symbol publishing for debug builds because I don’t need it for anything. This requires a crazy level of workaround because I can’t configure these things directly.

[rynowak]

This I agree with. The hard part is that what is “hostile” to one party is “normal and sane” to another.

Independent of my immediate needs, I also want to make an argument that providing a direct on/off for features rather than trying to infer based on presence of access tokens/feeds/etc is a more straightforward path. This can provide a better experience because rather that trying to infer a feature’s state from the required arguments you can just do what the developer asked for and validate the required arguments.

Providing a direct on/off for features that you expect to be present in ‘official builds’ also integrates nicely with the pipelines templates that arcade provides. Maybe my brain thinks of these things differently than others, but to me it’s a much strong statement of intent to say “I expect to publish to BAR” than to say “I have an access token”.

If I’m debugging why a target didn’t run, and I see:

<Target Name="Foo" Condition="'$(EnableFoo)'=='true'>
</Target>

I can go to the logs and look for EnableFoo without any more steps, I can look in my pipeline definition and see that I’m passing in EnableFoo, etc.

[ryanbrandenburg]

Mostly, yeah.