The composed build will set `PREBUILT_DOTNET_TOOL_DIR` to a location
where the dotnet tool can be copied from.
Long term we should get rid of the copy in favor of just using one
from a common location, but some of the Stage0 logic in the CLI build
system will need to change, I think.
Currently VSTS is producing duplicate package and they are running into
each other will producing
Today:
Linux x64 build definition: both .deb and .tar.gz
Ubuntu 16.04 build definition: both .deb and .tar.gz (ex.
dotnet-sdk-2.0.0-preview3-006477-linux-x64.tar.gz,
dotnet-sdk-debug-2.0.0-preview3-006477-linux-x64.tar.gz,
dotnet-sdk-internal-2.0.0-preview3-006477-linux-x64.tar.gz)
After this change:
Linux x64: .tar.gz
Ubuntu 16.04: .deb
No change for windows and macOS
Tested on Ubuntu with and without --linux-portable and windows
Our build scripts were pulling down all of buildtools and run.exe in
service of "clean.{cmd|sh}". While having consisent commands across
the repos is a good thing to strive for, we are pulling down a bunch
of additional stuff we don't need for simple commands that have well
known analogs (e.g. git clean).
If we had been all in on run.exe, this might have made sense, but we
aren't, so it feels like something we should clean up.
By doing this, we can stop downloading bootstrap from github when we
build (super dangerous anyway because changes in buildtools could have
broken us).
In addition, I changed the way we install dotnet to just invoke the
script in `scripts/obtain/` instead of downloading a version from
GitHub. This makes local development of changes to obtain easier and
removes yet another place we had to download a script.
The parameter passed to `exit` was always 0 (exit code of previous `echo` call). It seems to me that the intention is to terminate the script with the actual exit error code (!= 0).
When trying to cross build, Rid needs to change to the target Rid,
but architecture should use x64 as it as host.
In addition to the existing --architecture option, and additional --runtime-id option is required.
It duplicates functionality achieved by using `--runtime-id linux-x64`.
Remove it and fix callers.
Keep the the --linux-portable flag in the build scripts; that now calls
--runtime-id linux-x64 in the install script.
* Add support to build with the linux portable
* Pass targets to run for the linux portable
* Address PR comments
* Update the bootstrapper version
* Address the PR comments for improving the help text
* Fixing permissions
* Allow host info passed in from the command line to override machine settings
* Simplify the logic
* Address PR comments to keep a separate HostRid and HostOSName that are static
* Rename to BuildInfo.props
* Address PR comments
* Fix the previous merge
* Fix spacing
* Address PR comments
During the cli build, the cli downloads and executes the bootstrap
script from buildtools. The bootstrap script then downloads and executes
the dotnet-install script from cli, but in the 'rel/1.0.0' branch, not
the master branch.
This means that someone building cli's master branch will end up using
the dotnet-install.sh or dotnet-install.ps1 script from cli's rel/1.0.0
branch.
Fix that by telling the bootstrap script to download and use the version
of dotnet-install script from the master branch (which is the current
branch the user is building).
Ideally, we would just call the dotnet-install script in the current
repo/branch, but because the bootstrap script sits in the middle and is
part of a different repository, we can't.
This is a workaround for #5410.
Works around NuGet parallel restore timeouts becoming build failures when the machine has a slow connection, for example in our Docker Fedora containers.
* Switch to using new bootstrap script to initialize buildtools.
* Set up the version-specific shared runtime symlink in run-build so buildtools doesn't have to care about it.
* Address code review feedback.
* Addressed code review feedback.
* Change to using bootstrap script for Linux build as well.
* Change to using latest for CLI.
