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

Start flowing Microsoft.NETCore.App #24407

Merged
1 commit merged into from
May 4, 2021
Merged

Start flowing Microsoft.NETCore.App #24407

1 commit merged into from
May 4, 2021

Conversation

bricelam
Copy link
Contributor

(Includes PR #24405)

@bricelam bricelam force-pushed the flow6.0 branch 2 times, most recently from ce7a27b to 5281259 Compare March 15, 2021 22:18
@bricelam
Copy link
Contributor Author

Yep, we still need to figure out how to install it on Helix:

It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '6.0.0-preview.3.21164.8' was not found.
  - The following frameworks were found:
      6.0.0-preview.2.21154.6 at [C:\h\w\993C08DE\p\dotnet-cli\shared\Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

@bricelam
Copy link
Contributor Author

@smitpatel Any ideas on how to do this? aspnetcore has something here, but their scripts are way more complex than ours...

@smitpatel
Copy link
Member

Counter question would be where does the NetCore.App comes from? Does it come as a package from somewhere like our dependencies or does it come from dotnet installation? On helix machine we utilize the dotnet which is installed there already.
Generally it is up-to-date with latest public preview (or at least whatever they have allowed us to run tests). Asp.Net core installs local dotnet just like how it works in devbox, I would be very much against going down that path unless we really need this to work. That approach will create complicated helix build infra in our repo + additional runtime for each work-item to download and install dotnet.

@ajcvickers
Copy link
Member

@HaoK @dougbu Is there overlap here with the work being considered for ASP.NET to avoid downloading .NET every run on Helix?

global.json Outdated Show resolved Hide resolved
@dougbu
Copy link
Member

dougbu commented Mar 23, 2021

Is there overlap here with the work being considered for ASP.NET to avoid downloading .NET every run on Helix?

Some overlap certainly. For example, we'd both be much better off if Core-Eng solved dotnet/arcade#6005. What we do in dotnet/aspnetcore (installing runtimes in every Helix work item) isn't pretty (calling it a hack is too kind 😀) and may be overloading dotnetcli and dotnetclimsrc.

The obvious alternative would be to create correlation payloads containing the .dotnet/ folder. But, that implies consuming as many build agents as Helix agents. Even finding build agents for some of the platforms we test on (see the Helix matrix fan-out) may be a problem.

/cc @garath @MattGal @markwilkie @Chrisboh

@HaoK
Copy link
Member

HaoK commented Apr 26, 2021

FYI for aspnet we added the functionality for the helix sdk to install specific versions of additional runtimes now

@HaoK
Copy link
Member

HaoK commented Apr 26, 2021

You can see an example here https://github.com/dotnet/aspnetcore/blob/main/eng/helix/helix.proj#L43 where we use it to install our preview bits as an additional correlation payload

@bricelam
Copy link
Contributor Author

Thanks for doing all the legwork on this, Hao! I think I've managed to replicate the parts we need...

global.json Show resolved Hide resolved
@ghost
Copy link

ghost commented May 4, 2021

Hello @bricelam!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost
Copy link

ghost commented May 4, 2021

Apologies, while this PR appears ready to be merged, I've been configured to only merge when all checks have explicitly passed. The following integrations have not reported any progress on their checks and are blocking auto-merge:

  1. Azure Pipelines

These integrations are possibly never going to report a check, and unblocking auto-merge likely requires a human being to update my configuration to exempt these integrations from requiring a passing check.

Give feedback on this
From the bot dev team

We've tried to tune the bot such that it posts a comment like this only when auto-merge is blocked for exceptional, non-intuitive reasons. When the bot's auto-merge capability is properly configured, auto-merge should operate as you would intuitively expect and you should not see any spurious comments.

Please reach out to us at fabricbotservices@microsoft.com to provide feedback if you believe you're seeing this comment appear spuriously. Please note that we usually are unable to update your bot configuration on your team's behalf, but we're happy to help you identify your bot admin.

@ghost ghost merged commit afb7a04 into dotnet:main May 4, 2021
@bricelam bricelam deleted the flow6.0 branch May 4, 2021 18:01
bricelam added a commit to bricelam/efcore that referenced this pull request Jun 3, 2021
bricelam added a commit to bricelam/efcore that referenced this pull request Jun 7, 2021
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants