-
Notifications
You must be signed in to change notification settings - Fork 433
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
Core Tools OOP Host #3802
Core Tools OOP Host #3802
Conversation
…tools into aibhandari/core-tools-oop
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial review iteration.
{ | ||
FileName = inProc8FuncExecutablePath, | ||
FileName = funcExecutablePath, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do we use the --no-build
argument?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use it in line 626?
test/Azure.Functions.Cli.Tests/Azure.Functions.Cli.Tests.csproj
Outdated
Show resolved
Hide resolved
The table shared above doesn't seem to capture the expected supported scenarios. Shouldn't this reflect what is supported when
For inference, the path would always be:
|
@@ -418,15 +421,47 @@ private async Task<JObject> GetLocalSettingsJsonAsJObjectAsync() | |||
public override async Task RunAsync() | |||
{ | |||
await PreRunConditions(); | |||
var isVerbose = VerboseLogging.HasValue && VerboseLogging.Value; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move this logic that is specific to .NET to a different method and out of RunAsync
? That will help declutter this method and make the code easier to navigate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will also enable you to reduce the variables as you'll be able to drive the logic without needing to have an additional flag for OOP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved this logic into: ShouldExitAfterDeterminingHostRuntime
to clean up RunAsync
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few changes/improvements I'm tracking, but let's get this merged into the feature branch and collaborate there.
Issue describing the changes in this PR
resolves #3744
This PR creates the feature branch
feature/oop-host
, which has the OOP host build. This PR also includes checks for the user passing in the--runtime
param specifying the host and infers the host if that is not specified. I've also added tests which checks that we try to execute the correct func.exe (even though those tests technically fail since there is noinproc-6
orinproc-8
folder). We also only run on .NET 8 TFM and remove multi-targeting in the feature branch.For when the user specifies the
--runtime
parameter, these are the following scenarios we support today where the first row is the options the user may put in and the first column are the potential apps a user may have:Anything that does not have an X within it throws an error to the user with a helpful message on why the passed in host runtime is not valid.
For inference the path will be:
This is how the logic looks like today for the inference scenario:
FUNCTIONS_INPROC_NET8_ENABLED
is set- Run inproc8 host
- Run inproc6 host
Pull request checklist