Provide convention over configuration route

[nickbabcock]

Given a config of

strategy:
  matrix:
    stable:
      rustup_toolchain: stable
    beta:
      rustup_toolchain: beta
steps:
  - template: rustup.yml
    parameters:
      rustup_toolchain: $(rustup_toolchain)

Listing the rustup_toolchain parameter seems redundant (one has to type out "rustup_toolchain" 3 times). I've played around with the following convention in some templates:

1. Use parameter if provided
2. Global RUSTUP_TOOLCHAIN if available
3. Default to stable if none are available

By relying on this global variable, we condense the config (and if subsequent templates relied on that parameter, the savings would be even greater). Resulting in:

strategy:
  matrix:
    stable:
      rustup_toolchain: stable
    beta:
      rustup_toolchain: beta
steps:
  - template: rustup.yml

These global variables can be documented. There are of course downsides to this approach (a breaking change in the variable name may go undetected, but maybe there will be template versions like tasks (self-imposed version maybe like rustup-1.yml or rustup-2.yml 🤔 )).

[epage]

I understand the concern over verbosity. I prefer the explicit parameter passing (ran into so many other issues with sloppy behavior in Azure Pipelines) but I do see the value in this.

Darned if we do, darned if we don't, so why not?

[jonhoo]

I'm going to close this now that the library has moved strongly towards convention over configuration by exposing only a way to install rust (with components and targets) and a very opinionated default template.