Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upRemove run.exe and config.json #21608
Conversation
sbomer
added some commits
Dec 15, 2018
This comment has been minimized.
This comment has been minimized.
|
This is also worth considering if we still rely on old dependencies flowing https://github.com/dotnet/versions/blob/59a50129040abf769dc33a60ff4a36ec74c813ba/Maestro/subscriptions.json#L204 as well as the runtests scripts. That was the main reasons I didn't rip it out. But this also sounds good to start transitioning. |
sbomer
added some commits
Jan 2, 2019
This comment has been minimized.
This comment has been minimized.
|
Thanks @hoyosjs, I'll update the subscription once this is in. |
sbomer
added some commits
Jan 10, 2019
sbomer
requested a review
from
echesakovMSFT
Jan 11, 2019
sbomer
requested a review
from
hoyosjs
Jan 11, 2019
sbomer
added some commits
Jan 11, 2019
jashook
approved these changes
Jan 11, 2019
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Also in Line 1587 in 8a15c6b |
sbomer
added some commits
Jan 15, 2019
hoyosjs
approved these changes
Jan 16, 2019
|
|
sbomer
added some commits
Jan 17, 2019
This comment has been minimized.
This comment has been minimized.
|
Successful arcade build with latest changes: https://dnceng.visualstudio.com/internal/_build/results?buildId=76197. |
sbomer
changed the title
[WIP] Remove run.exe and config.json
Jan 22, 2019
This comment has been minimized.
This comment has been minimized.
|
@dotnet-bot help |
This comment has been minimized.
This comment has been minimized.
|
Welcome to the dotnet/coreclr Perf help The following is a list of valid commands on this PR. To invoke a command, comment the indicated phrase on the PR The following commands are valid for all PRs and repositories. Click to expand
The following jobs are launched by default for each PR against dotnet/coreclr:master. Click to expand
The following optional jobs are available in PRs against dotnet/coreclr:master. Click to expand
Have a nice day! |
This comment has been minimized.
This comment has been minimized.
|
Welcome to the dotnet/coreclr Repository The following is a list of valid commands on this PR. To invoke a command, comment the indicated phrase on the PR The following commands are valid for all PRs and repositories. Click to expand
The following jobs are launched by default for each PR against dotnet/coreclr:master. Click to expand
The following optional jobs are available in PRs against dotnet/coreclr:master. Click to expand
Have a nice day! |
This comment has been minimized.
This comment has been minimized.
|
@dotnet-bot test this please |
This comment has been minimized.
This comment has been minimized.
|
Welcome to the dotnet/coreclr Repository The following is a list of valid commands on this PR. To invoke a command, comment the indicated phrase on the PR The following commands are valid for all PRs and repositories. Click to expand
The following jobs are launched by default for each PR against dotnet/coreclr:master. Click to expand
The following optional jobs are available in PRs against dotnet/coreclr:master. Click to expand
Have a nice day! |


sbomer commentedDec 20, 2018
•
edited
This moves us one step away from buildtools and towards arcade.
This replaces run.sh and run.cmd (and all invocations) with "dotnet.sh msbuild" and "msbuild.cmd".
All of the arguments that used to be implicitly generated by run.exe and config.json are now explicit, resulting in longer (but easier to copy+paste) commands. Some of these arguments are likely unnecessary, but in this change my goal is just to match the run.exe behavior. Later, I would like to go through and clean up parameters that don't need to be passed in every invocation. I might also consider moving more of the common arguments out into variables in a later change.
Some of the wrapper scripts now have limited support for parsing "-Argument=Value" style parameters, to support our existing buildpipeline infrastructure, since I thought this was easier to test than changing our buildpipeline definitions. We can remove that parsing logic once we stop using buildpipeline (hopefully soon!).
I'm still validating this change with our buildpipeline official builds, so don't merge yet.