When running the CLI builds on the new build agents, the CentOS
build failed with the following error:
2017-01-26T20:39:30.0800810Z Step 4 : RUN yum -q -y install unzip libunwind gettext libcurl-devel openssl-devel zlib libicu-devel
2017-01-26T20:39:30.3020500Z ---> Running in 97affb106685
2017-01-26T20:39:40.3872390Z [91mError: libselinux conflicts with fakesystemd-1-17.el7.centos.noarch
Swapping the the "fakesystemd" package with the real "systemd" package
fixed the issue, which was recommended in http://stackoverflow.com/a/36632668.
This issue hasn't been seen on the official builds because the build
agents in that pool have the Docker image cached, and they are using an
older version of the centos:7.1.1503 image which appears not to have
this issue.
* Insert test platform v15.0.0-preview-20160120-03.
Remove OutputType from test project templates since it is
automatically determined by Microsoft.NET.Test.Sdk.
* Update testplatform v15.0.0-preview-20170123-02.
* Reduce test target complexity [and running time]
* WiP
* Enable building tests via solution
Remove deprecated tests
Make Microsoft.DotNet.Tools.Tests.Utilities portable-only
Remove MSI tests from the solution as they are the only tests that currently require dekstop.
* Enable building of tests
* Move migration tests to TA to allow them to self-restore
* Reduce project nesting and test directory name
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
