Skip to content

[Helix] Don't fail fast on ef tool install issues (may be already installed) #20958

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

Merged
merged 6 commits into from
Apr 18, 2020

Conversation

HaoK
Copy link
Member

@HaoK HaoK commented Apr 17, 2020

No description provided.

@ghost ghost added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Apr 17, 2020
@HaoK HaoK changed the title Debug helix ef tool failures [Helix] Don't fail fast on ef tool install issues (may be already installed) Apr 17, 2020
@HaoK HaoK marked this pull request as ready for review April 17, 2020 21:50
@HaoK HaoK requested review from BrennanConroy, Tratcher and a team April 17, 2020 21:50
@HaoK
Copy link
Member Author

HaoK commented Apr 17, 2020

Unrelated to this PR, so interesting @dougbu looks like the skip-ci only affects the aspnetcore-pr-validation-temp pipeline https://dev.azure.com/dnceng/public/_build?definitionId=279

@HaoK HaoK merged commit 02bb671 into master Apr 18, 2020
@HaoK HaoK deleted the haok/debug branch April 18, 2020 08:58
@Pilchie
Copy link
Member

Pilchie commented Apr 18, 2020

Do we understand if this does the right thing if the wrong version of the ef tool is installed?

@davidfowl
Copy link
Member

Seem like we should install or update.

@HaoK
Copy link
Member Author

HaoK commented Apr 18, 2020

So my impression is that you can install multiple versions of the tool, and the failure we were running into was that the version we were trying to install was already installed (maybe the SDK caught up to our runtime version?)

@HaoK
Copy link
Member Author

HaoK commented Apr 18, 2020

dotnet tool install dotnet-ef --global --version {Options.EfVersion} so we are specifying the exact version we want (the AspNetRuntime version)

@Pilchie
Copy link
Member

Pilchie commented Apr 18, 2020

We should verify that installing multiple versions actually works the way we expect. @wli3 - do you know about this?

@davidfowl
Copy link
Member

Does it need to be installed globally? Seems like we should be installing it into a subfolder and using that instead no?

@BrennanConroy
Copy link
Member

It should be installed in a local folder, I believe the DOTNET_CLI_HOME variable controls that. But it looks like we are no longer setting that after switching to the C# runner.

@HaoK
Copy link
Member Author

HaoK commented Apr 18, 2020

Okay I can open a new PR on monday that switches to installing the tool non globally

@dougbu
Copy link
Contributor

dougbu commented Apr 18, 2020

The bug here is not setting $env:DOTNET_CLI_HOME anymore. We should avoid global changes on the agents where possible because they are not recreated from an image after each use. Put another way, we set $env:DOTNET_CLI_HOME for reasons.

@davidfowl
Copy link
Member

This should be part of the helix package #20876

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants