Add support for FUNCTIONS_WORKER_RUNTIME in host.json

[pragnagopa]

host.json should support FUNCTIONS_WORKER_RUNTIME setting. Right now the CLI uses that setting for figuring out your app's type, since many operations (init, new, start, publish, etc) are language specific. Currently that is stored in local.settings.json which is not committed in the repo.

[pragnagopa]

@paulbatum @ahmelsayed

[fabiocav]

This needs additional discussion with @pragnagopa @ahmelsayed @mathewc

[ahmelsayed]

as Pragna mentioned. the main issue currently is that the CLI used that value to figure out how to build, run, and publish the app. However, since that setting is stored in local.settings.json which doesn't make it to source control, it makes the experience a bit odd especially for things like CIs or when you clone a new project

[EddieDL]

@ahmelsayed How do you deal with this issue on CI, or multiple developer environments? It seems like there isn't any real solution and we just need to train/document what setting it should be.

[fabiomilheiro]

Any solutions for this?
I'm struggling with knowing what to put in the host.json file.

I also tried adding an appsetting FUNCTIONS_WORKER_RUNTIME=dotnet but nothing.

[fabiocav]

@fabiomilheiro can you please clarify the issue you're seeing with your app?

[fabiomilheiro]

@fabiocav, the app works well locally and I go to Azure portal, after deploying the app.
I load a function using the Test/Run feature and get a 404:

Trying to get the URL using the "Get function URL" button achieves the same result.

The below is the function definition:

As mentioned above, it works locally:

So I'm assuming there is some problem with my host.json not having the necessary runtime setting to specify the language.

Unfortunately, 404 is not very obvious so I'm struggling to get to the root cause.

[fabiomilheiro]

Found the problem. I created the azure function app via Pulumi (which uses Terraform) and the version is ~1 by default.
Unfortunately, when we deploy a function app with version ~3, it does not complain. It simply does not work.

I answered here: https://stackoverflow.com/a/67494279/169034

[fabiocav]

Glad to hear you found the issue.

For future issues, it might be helpful to start with new issue describing the problem as the template also requests information that would enable us to look at the logs for your app, which would have made it simpler to detect what was happening.

[AdamCoulterOz]

@fabiocav I have a problem which would benefit from the same solution (specifying the FunctionWorkerRuntime in the host.json) ... and I agree completely with this issue and @pragnagopa 's original statement, and that fundamentally it is incorrect to store this value in local.settings.json from an architectural perspective:

host.json should support FUNCTIONS_WORKER_RUNTIME setting

I am deploying my function app from an Azure DevOps pipeline using the Azure CLI task to inject the auth token:

func azure functionapp publish myAwesomeFunction

# Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell, --custom]
# Your Azure Function App has 'FUNCTIONS_WORKER_RUNTIME' set to 'dotnetIsolated' while your local project is set to 'None'.
# You can pass --force to update your Azure app with 'None' as a 'FUNCTIONS_WORKER_RUNTIME'

So following what it said, I added --csharp, to which I get the following error:

func azure functionapp publish myAwesomeFunction --csharp

# Your Azure Function App has 'FUNCTIONS_WORKER_RUNTIME' set to 'dotnetIsolated' while your local project is set to 'dotnet'.
# You can pass --force to update your Azure app with 'dotnet' as a 'FUNCTIONS_WORKER_RUNTIME'

But then if I add --force it will overwrite my preset FUNCTIONS_WORKER_RUNTIME application setting, which needs to be dotnet-isolated. I don't get this problem on my local because the local.settings.json file has the FUNCTIONS_WORKER_RUNTIME.

I would argue the runtime value is not actually an environment setting, but is hard coupled to the functional type / source code and should be in the host.json file which actually gets added to source control. It will then be present on the build server, removing the need to append either --csharp or --force, and will stop the function publish cli messing with the preset FUNCTIONS_WORKER_RUNTIME value.

I do understand the approach you've taken with using Application settings to store function type configuration as a way to be light-touch / flexible with changes impacting the Azure Resource Type itself, but based on the above reasoning the following are all candidates to move to Function runtime settings as strongly typed settings passed through to the function host:

• Runtime (type, e.g. dotnet, dotnet-isolated, java, node, python, powershell)
• AppInsights (service connection)
• ProxySettings
• Environment (Development, Staging, Production)
• Homepage (enabled/disabled)
• Compilation (release/debug)
• FeatureFlags (enabled array)
• SecretStorage (blob/files)
• Storage (service connection -> using system assigned managed identity too please)
• EditMode (readwrite, readonly)
• ExtensionVersion (~1, ~2, ~3)
• CompatibilityMode (target version)
• ProcessCount (int)
• etc

Even if you just support current known application settings in the next major version, and add supplemental as application settings incrementally through a major release lifecycle, that would be a big win.

[fbjerggaard]

@fabiocav Are there any plans to do something about this? I have the same issue as @AdamCoulterOz and I don't really see how I can publish the function with func azure functionapp publish before this is fixed/changed

[qstyler]

This is a very uncomfortable situation. My only workaround is to create a settings.json file next to the ignored local.settings.json that CI/CD script would rename to the target name.
But this seems very hacky.