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

Allow overriding HOME variable in dotnet remote builds #15171

Merged
merged 1 commit into from
Jun 3, 2022
Merged

Conversation

mauroa
Copy link
Contributor

@mauroa mauroa commented Jun 1, 2022

With remote builds, a dedicated dotnet location is being used so the right versioning can be used and managed from VS in Windows. This dedicated dotnet location requires a custom .home location so the donet and nuget caches doesn't conflict with the global installation.

We need to consider and use this custom .home location when running dotnet commands remotely so the right caches are used

This should fix Bug: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1543495

@mauroa mauroa requested a review from dalexsoto June 1, 2022 15:38
@mauroa mauroa self-assigned this Jun 1, 2022
@mauroa mauroa added the not-notes-worthy Ignore for release notes label Jun 1, 2022

//In case the XMA dotnet has not been installed yet
if (!File.Exists (dotnetPath)) {
if (File.Exists (dotnetPath)) {
Environment.SetEnvironmentVariable ("DOTNET_XMA_HOME", Path.Combine (sdkRootPath, ".home"));
Copy link
Member

Choose a reason for hiding this comment

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

What happens if you just set HOME here? If that works, I don't think you need the rest of the changes.

Copy link
Contributor Author

@mauroa mauroa Jun 1, 2022

Choose a reason for hiding this comment

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

Yeah, I thought about it but I was worried about messing up other things. But the set "should" affect only the current process, so it might work. I'll do a quick try

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rolfbjarne it doesn't work because who needs the HOME override is the dotnet process, not the Build (agent) process

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could avoid the DOTNET_XMA_HOME and use HOME instead but the environment change on the base tasks would be needed anyways

Copy link
Member

Choose a reason for hiding this comment

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

That's weird, if you set an environment variable for the current process, all child processes should inherit that variable

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rolfbjarne It works, I just updated the PR by changing only the Build agent and setting HOME. I was verifying the wrong bits

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@rolfbjarne
Copy link
Member

Regarding this:

IMPORTANT: I have doubts about these two usages of the DOTNET_HOST_PATH variable:

You'll have to add it to the EnvironmentVariables property (from the base ToolTask class): https://docs.microsoft.com/en-us/dotnet/api/microsoft.build.utilities.tooltask.environmentvariables?view=msbuild-17-netcore

This looks like dead code, I can't see it used anywhere, so you could probably just delete it:

<ItemGroup>
<_BTouchCompileCommand Include="$(DOTNET_HOST_PATH)" />
<_BTouchCompileCommand Include="$(RoslynTargetsPath)/bincore/csc.dll" />
</ItemGroup>

I haven't found how to pass the HOME variable in those cases and if it's needed or not. @rolfbjarne I wait for your confirmation

I think it would be required.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

With remote builds, a dedicated dotnet location is being used so the right versioning can be used and managed from VS in Windows. This dedicated dotnet location requires a custom .home location so the donet and nuget caches doesn't conflict with the global installation.

We need to consider and use this custom .home location when running dotnet commands remotely so the right caches are used
@vs-mobiletools-engineering-service2
Copy link
Collaborator

📋 [PR Build] API Diff 📋

API diff (for current PR)

ℹ️ API Diff (from PR only) (please review changes)

API diff: vsdrops gist

Xamarin
.NET
Xamarin vs .NET
iOS vs Mac Catalyst (.NET)

API diff (vs stable)

✅ API Diff from stable

API diff: vsdrops gist

Xamarin
.NET
Xamarin vs .NET
iOS vs Mac Catalyst (.NET)

Generator diff

Generator Diff (no change)

Pipeline on Agent XAMBOT-1108.Monterey'
Hash: 061d395ad37f0ee0ae5dd13c6416a37206565321

@vs-mobiletools-engineering-service2
Copy link
Collaborator

💻 [PR Build] Tests on macOS Mac Catalina (10.15) passed 💻

All tests on macOS Mac Catalina (10.15) passed.

Pipeline on Agent
Hash: 061d395ad37f0ee0ae5dd13c6416a37206565321

@vs-mobiletools-engineering-service2
Copy link
Collaborator

📚 [PR Build] Artifacts 📚

Packages generated

View packages

Pipeline on Agent XAMBOT-1107.Monterey'
Hash: 061d395ad37f0ee0ae5dd13c6416a37206565321

@vs-mobiletools-engineering-service2
Copy link
Collaborator

❌ [CI Build] Tests failed on VSTS: simulator tests iOS ❌

Tests failed on VSTS: simulator tests iOS.

Test results

1 tests failed, 147 tests passed.

Failed tests

  • framework-test/watchOS 32-bits - simulator/Debug: Crashed

Pipeline on Agent XAMBOT-1017.Monterey
Merge 061d395 into 3337321

@mauroa
Copy link
Contributor Author

mauroa commented Jun 3, 2022

@rolfbjarne is this ready to merge?

@rolfbjarne
Copy link
Member

Test failure is unrelated (https://github.com/xamarin/maccore/issues/2558).

@rolfbjarne rolfbjarne merged commit ac97efd into main Jun 3, 2022
@rolfbjarne rolfbjarne deleted the dev/mag/main branch June 3, 2022 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not-notes-worthy Ignore for release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants