* Switch repo to use native AzDO container support
This is a major refactor of the YAML used by the installer repo. The goal is to utilize the native container support that AzDO provides, rather than building containers on the fly and issuing commands using custom infrastructure. To do this, the YAML requires a bit of a refactor. The matrix strategy approach used by the repo to build a ton of different OS's does not work with containers, because a matrix strategy only changes the variables available to each build command. It cannot change the AzDO host environment. In order to resolve this, I refactored build.yml to take and use optional container names. In the process of doing this, I discovered a number of other things about the old YAML that just happened to 'accidentally' work and fixed them or did general cleanup. Including:
- This construct, used in build.yml, does not work as you might expect. If the parameter is not declared as a boolean (or not declared at all), this evaluates to "does this parameter exist", not "is it true":
```
${{ if parameters.pgoInstrument }}:
```
- I fully specified all the parameters and their types to avoid issues in the future.
- Build pool selection was moved to build.yml
- Removed some unused parameters.
- There was a **very** subtle indentation change here: 762d2966ee/.vsts-ci.yml (L275-L281). This meant that this leg ran in both PR and official builds. I have no idea whether this was the intention or not, but I kept it this way and reorganized the file.
**One change of note:** One of the upsides of the original matrix based approach is that job dependencies are simple. The jobs generated by the matrix are referred to in `dependsOn` lists only by the original job that contains the matrix. That keeps the dependsOn list small even if the number of jobs generated is large. Installer has a large set of independently addressable jobs now. Normally, we would solve this by using the arcade jobs template. The jobs template takes a set of jobs and automatically adds dependsOn for the publishing jobs. BUT, AzDO does not allow templates to be passed as parameters to other templates. This would mean that you couldn't use the build.yml template in conjunction with the jobs template and would have to list all the installer jobs as dependencies. This list would be hard to keep up to date. To avoid this, I used a new feature of publishing (`publishAssetsImmediately`) which uses the Publish To Build Asset Registry job to do the actual publishing call, and put it in a separate phase, then eliminated the post-build.yml call. This means that the publishing stage depends on all jobs in the build stage, and does not need to address them individually. Eliminating the post-build.yml stage may seem odd, but this is what actually happens when `publishAssetsImmediately` is set to true anyway.
- Added an option '--buildindocker <osname>' to build.sh
- Fixed bug which caused packaging to be skipped by default.
- Fixed bug which caused tarballs to be generated twice.
- Fixed bug to propagate build params(like debug, nopackage) to docker build.
Decompose into self-contained granular components
Provide reasonable defaults for cross cutting concerns, allowing for independent execution of steps
Start unifying Windows/Bash architecture
fix Bash CI scripts
dockerbuild.sh _common.sh path
Add missing restore-packages.sh
Copy/paste issues
Quote $SOURCE
fix .gitignore
PR Feedback
Merge in @SridarMS's work to avoid redownloading DNX
enabling build of dotnet-build
merge in @SridharMS's CentOS changes
Enable building FSC
enable restoring specific subdirectories
Fix dnx version check
Add missed dependency
Fix pathing to tests
Match Linux build version to Windows, fixing linux tests as a side effect.
workaround for coreclr#2215
fix pathing issue
disable building in docker
BUILD_IN_DOCKER was set, somehow...
fix headers
Earlier I made changes for windows to follow the 'major.minor.build.revision' model for versioning.
This format is enforced by MSI authoring tools. It makes sense to follow the same format for Linux and OSX too, now we have uniform version numbers for all platforms.
The Debian Package should have the same version as the rest of the packages
being created as a part of the full build. These changes enable that.
NOTE: The debian package revision is unused but still included in the package
to allow for hyphens in the package version. (https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version)
