Update dogfood support

[dsplaisted]

EDIT: This PR has changed somewhat, see #1944 (comment) for a more up-to-date description

This adds scripts that are created when you run the main build script that will set up a "build" or "test" environment.

The "build" environment basically just sets you up so that the version of dotnet on the path is the "Stage 0" one that would be used by the build script.

The "test" environment is set up to use the "Stage 1" versions of the SDK assets when you build. So if you want to manually repro a test scenario, or to experiment with local changes, then you can do that in the test environment.

We had scripts like this before we moved to repo toolset. It looks like the -dogfood argument to the build script was supposed to do something similar, but that didn't work in my workflow because it doesn't set the environment variables in the calling process.

With this PR, the "build" environment script is generated as artifacts\sdk-build-env.bat and the test environment script (for the Debug configuration) is generated as artifacts\Debug\sdk-test-env.bat. That way there's less duplication of path logic, etc (though it is still duplicated between build.ps1 and the TestContext code).

@tannergooding @nguerrera @livarcocc @wli3 @peterhuene @johnbeisner

[nguerrera]

I've been using -dogfood and then running a cmd from there (because powershell is not my thing)

(Edit: You need to run build\dogfood.cmd to get the powershell interactive behavior.)

[nguerrera]

See #1820

[nguerrera]

I do prefer it this way

[nguerrera]

I believe we used to have nix .sh files you could source. We should recover that too

[dsplaisted]

I think sourcing build.sh - dogfood should work, right? So perhaps we don't need to generate separate shell scripts.

[tannergooding]

This looks like it is just making the overall process needlessly more complicated.

As of today, it should be a one step process (build.cmd -dogfood or build.sh -dogfood), this is changing it to be a multi-step process (build.cmd + <artifacts>\sdk-build-env.bat)

[dsplaisted]

@tannergooding I don't think build.cmd -dogfood works. That doesn't set the environment variables in the session you call it from. I think what @nguerrera was doing was calling build.ps1 -dogfood from a powershell session in a way that the environment variables would apply to that session. Then from powershell he was launching cmd to get a non-powershell command prompt with the appropriate variables set.

So unless I'm missing something, I think that generating the scripts ends up being less complicated than the process we have today.

[nguerrera]

There's a -noexit that causes powershell to stay alive in build\dogfood.cmd. What I do is run build\dogfood.cmd, then run cmd from inside the unexited powershell.

There was a bug in -dogfood that I fixed in #1820 that may not be in all branches.

(Edit: Updated to reflect that you currently need to use build\dogfood.cmd, not build -dogfood)

[johnbeisner]

This is my understanding:
"build.cmd -dogfood" means "set up a dogfood environment, do a restore, and also do a compile"

"build/dogfood.cmd" simply translates to "build/build.ps1 -dogfood"

"build/build.ps1 -dogfood" is what we need to fix.

[dsplaisted]

I've made some changes based on discussions we've had. This PR now does the following:

• Creates an artifacts\sdk-build-env.bat script. This is the same as in the first iteration
• If the -dogfood option is specified, any other actions (-restore, -build, etc) specified will be ignored
• You can specify a command after -dogfood in order to launch that process in the dogfood context. So you can do build -dogfood cmd or build -dogfood devenv
• You can also set the DOTNET_SDK_DOGFOOD_SHELL environment variable to specify a default process to launch for -dogfood. So if you have it set to cmd, you can simply run build -dogfood and it will switch your shell to a dogfood context (which you can exit out of with exit).
• Includes @nguerrera's dogfood fixes from Fix dogfood script #1820, and adds another fix on top (the Microsoft.NET.Build.Extensions targets weren't being set correctly)
• Allows overriding the artifacts directory with the DOTNET_SDK_ARTIFACTS_DIR environment variable. This lets you share a copy of a repo between Windows and Linux (especially Bash on Windows) by overriding the artifacts directory in one of the contexts so they don't conflict with each other.

@tannergooding @nguerrera @livarcocc @peterhuene @wli3 @johnbeisner

[nguerrera]

Should the sh have the same early return here?

[dsplaisted]

I've added this now. Turns out previously sourcing the script didn't work because it had an exit at the end. I've disabled that if you pass --dogfood.

[tannergooding]

@jaredpar, will having a flag that ignores other flags (such as build/restore/test) conflict with repo API?

[jaredpar]

The actual repo API isn't set. For example I can't give any concrete guidance like

repo will have build.cmd which accepts parameters -build, -restore, etc ...

But we do understand the rough concepts that will be involved. In particular we will need to be able to separate the restore, build, publish and test phases of a repository. Each of those needs to be executable as an individual action. The guidance I would give is avoid making it hard to separate those back out in the near future.

[dsplaisted]

@dotnet-bot test OSX10.12 Debug