Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Design]Use global.json and switch to netcoreapp2.2 #661

Closed
wants to merge 5 commits into from

Conversation

ryanbrandenburg
Copy link
Contributor

No description provided.

@ryanbrandenburg ryanbrandenburg changed the title Use global.json and switch to netcoreapp2.2 [Design]Use global.json and switch to netcoreapp2.2 May 2, 2018
Copy link
Contributor

@natemcmaster natemcmaster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A good start. Commented below with some more things to consider.

@@ -431,7 +423,9 @@ function __get_dotnet_sdk_version {
Write-Warning "dotnet SDK version overridden by KOREBUILD_DOTNET_VERSION"
return $env:KOREBUILD_DOTNET_VERSION
}
return Get-Content (Join-Paths $PSScriptRoot ('..', 'config', 'sdk.version'))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we don't generate global.json anymore, let's also remove usages of KOREBUILD_DOTNET_VERSION, both in .ps1 and .sh scripts.

@@ -61,7 +61,8 @@ __ensure_macos_version() {

__get_dotnet_sdk_version() {
local src="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
version=$(< "$src/../config/sdk.version" head -1 | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//')

version=$(< "$src/../../../global.json" head -1 | grep -Po '"version":.*?[^\\]",' global.json)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only works when building inside aspnet/BuildTools. You'll need to look for the global.json file in the repo root, not a relative path to this script.

Also, it would be better to use jq (and fallback to python) to read the json file. See

if jq '.' "$config_file" >/dev/null ; then
config_channel="$(jq -r 'select(.channel!=null) | .channel' "$config_file")"
config_tools_source="$(jq -r 'select(.toolsSource!=null) | .toolsSource' "$config_file")"
else
__warn "$config_file is invalid JSON. Its settings will be ignored."
fi
elif __machine_has python ; then
if python -c "import json,codecs;obj=json.load(codecs.open('$config_file', 'r', 'utf-8-sig'))" >/dev/null ; then
config_channel="$(python -c "import json,codecs;obj=json.load(codecs.open('$config_file', 'r', 'utf-8-sig'));print(obj['channel'] if 'channel' in obj else '')")"
config_tools_source="$(python -c "import json,codecs;obj=json.load(codecs.open('$config_file', 'r', 'utf-8-sig'));print(obj['toolsSource'] if 'toolsSource' in obj else '')")"
else
__warn "$config_file is invalid JSON. Its settings will be ignored."
fi
else
__warn 'Missing required command: jq or pyton. Could not parse the JSON file. Its settings will be ignored.'
fi
for example.

@@ -210,6 +215,12 @@ private int UpdateDependencies(DependencyVersionsFile localVersionsFile, Depende
newValue = KoreBuildVersion.Current;
Log.LogMessage(MessageImportance.Low, "Setting InternalAspNetCoreSdkPackageVersion to the current version of KoreBuild");
}
else if (var.Key == "SdkPackageVersion")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming what about: DotNetCliVersion?

We should also add update logic for the "msbuild-sdks" section of the global.json file. See https://github.com/aspnet/BuildTools/tree/dev/src/Microsoft.DotNet.GlobalTools.Sdk#usage for example. We will need this more as we migrated Internal.AspNetCore.Sdk and others away from being a PackageReference and towards being proper MSBuild SDKs.

Also, maybe we should have this information stored separately. Dependencies.props was really only mean for PackageReference versions. Maybe use a new file named Tooling.props or something? Just a thought...haven't committed to the idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 should be its own item right? Once I touch 50 repos this is already going to be a messy change, I'd really rather not complicate it further.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If by 2 you mean updating the "msbuild-sdks", then no, we need that before we can take this change. The msbuild-sdks section is required in at least 4 repos for the global tool shim stuff I just added yesterday.

{
var globalJson = JsonConvert.DeserializeObject<Dictionary<string, object>>(File.ReadAllText(_path));

var sdkDict = (Dictionary<string, object>)globalJson["sdk"];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double check this section of the file exists first. It may not.


public void SetSdkVersion(string version)
{
var globalJson = JsonConvert.DeserializeObject<Dictionary<string, object>>(File.ReadAllText(_path));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Handle the case were the file may not exist at all.

@natemcmaster
Copy link
Contributor

By the way, it might be good to take the netcoreapp2.2 update and global.json changes separately. I don't believe these need to be done at the same time. The global.json work is less urgent and has deeper implications on how KoreBuild functions.

Some unanswered questions we'll have to address:

  • How can we check for a min sdk version? If KoreBuild requires a minimum version of the CLI, how can we check and enforce that.
  • How can we isolate task dependencies? Today, KoreBuild's tasks are tied to the same version of dependencies that ship in MSBuild itself, like NuGet and JSON.NET. We need to break that dependency and isolate tasks in order to make the decoupling work. I suspect we can do this incrementally, but it's something we should have a plan for first.
  • How can we ensure we install required runtimes for tools? The console tools bundled in KoreBuild depend on a .NET Core runtime. How can we ensure this is installed? (Btw, this is addressed today by only using netcoreapp2.0 and the files/KoreBuild/config/runtime.version file. Updating to netcoreapp2.2 breaks that assumption)

@natemcmaster
Copy link
Contributor

Sorry to pile it on, but one more question to consider:

  • Does aspnet/Universe need to ensure the same CLI version is used in all repos? If so, how will we override global.json? We do this today be re-generating global.json on each build, and overriding the korebuild-lock.txt file in aspnet/Universe.

@ryanbrandenburg
Copy link
Contributor Author

Results from meeting: We're going to punt 1 and 2, our solution for 3 is to only have netcoreapp2.0 projects. As for the other comment we all agreed that Universe should enforce its SDK on all modules via replacing the global.json with its own (the same way we do for korebuild-lock.json)

@ryanbrandenburg ryanbrandenburg force-pushed the rybrande/netcoreapp22 branch from 372f180 to 4a9f641 Compare May 3, 2018 22:04
@ryanbrandenburg
Copy link
Contributor Author

This is stale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants