Refactor `prep-source-build.sh` to improve the UX

[ellahathaway]

As described in the discussion in dotnet/installer#18726 (comment), prep-source-build.sh (previously prep.sh) as expanded enough where we have exceeded the original option design. There are significantly more options than there previously were, and it is clogging the usability and UX of the script. As such, this script needs a redesign.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[omajid]

How about splitting it into separate scripts for each responsibility?

• One to download dependencies
• One to remove binaries
• (Third script for additional responsibility)

For the common dev workflow, perhaps we can add a eng/prep-dev.sh that just calls the other scripts one by one with standard dev workflow arguments?

[ellahathaway]

For the common dev workflow, perhaps we can add a eng/prep-dev.sh that just calls the other scripts one by one with standard dev workflow arguments?

I like this idea. I think having separate scripts keeps things clean and solves the problem of having a single bulky script. A single script that calls the other scripts in standard flow and default form is necessary if we decide to take this approach.

[ellahathaway]

After discussing this offline with @mthalman and @MichaelSimons, we decided that we should adopt an "opt-in" approach for the script. This means that the will have separate commands for different functions and an "all" command that runs all the commands (all will be the command that sets up the common dev workflow).

• ./prep.sh artifacts will download the artifacts
• ./prep.sh bootstrap will run the bootstrapping
• ./prep.sh binaries will run the binary tooling
• ./prep.sh all will download the artifacts, run the bootstrapping, and run the binary tooling.

This setup should make it easier for users to run individual features, which isn't straightforward in the current script. As part of this change, we need to decide if each command should have its own script that is called within the ./prep.sh script or if all functionality will live in the single prep script.

Additionally, the script's location also needs reconsideration. It used to be at the root of the VMR but moved to eng/ in #4174. If we split the script into "helper" scripts, they should stay in eng/, but the main "caller" script might be better off back at the VMR root.

[tmds]

./prep.sh artifacts will download the artifacts

Is there also something for prebuilts, or is that not longer a thing?

./prep.sh bootstrap will run the bootstrapping

What does this do?

./prep.sh binaries will run the binary tooling

This is for downloading the SDK? Are there other tools to be downloaded?

I think of the prep script of something that downloads and extracts. Is that right? Or does/will it do more?

[ellahathaway]

Is there also something for prebuilts, or is that not longer a thing?

Oh yep, this is still a command in prep. ./prep-source-build.sh prebuilts will continue to be a command.

What does this do?

It runs the tooling that removes non-SB allowed binaries: #4089

I think of the prep script of something that downloads and extracts. Is that right? Or does/will it do more?

This is still true! It preps the VMR for source-build. This prep work includes downloading, extracting, and cleaning.