Does anybody know if its possible to pass / inject a const connection string (or other configuration value) from the Azure Functions Configuration blade?
Take this binding signature for instance:
[Function("APIHttpInput")]
[CosmosDBOutput("%CosmosDb%", "%CosmosContainerOut%", ConnectionStringSetting = "CosmosDBConnection", CreateIfNotExists = true)]
public static async Task<object> RunAsync(
[HttpTrigger(AuthorizationLevel.Function, "post", Route = "cosmosin")] HttpRequestData req,
FunctionContext executionContext)
{
var logger = executionContext.GetLogger("APIHttpInput");
logger.LogInformation("C# HTTP trigger function processed a request.");
// etc...
}
It gets the connection string from local.settings.json, which is fine it works that way file but they're not overwritten in the default CI/CD pipeline and isn't meant to be pushed to production.
I've read the official documentation: https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection#customizing-configuration-sources but this doesn't allow utilise them in the binding because they're passed in through DI (which is great, but not quite).
An alternative is to manually write them to Cosmos and use DI. This isn't really what I want because I've got the following function that consumes data:
[Function("APICosmosTrigger")]
//[CosmosDBOutput("%CosmosDb%", "%CosmosContainerOut%", ConnectionStringSetting = "CosmosDBConnection", CreateIfNotExists = true)]
public static void RunCosmos([CosmosDBTrigger(
databaseName: "%CosmosDb%",
collectionName: "%CosmosContainerOut%",
ConnectionStringSetting = "CosmosDBConnection",
LeaseCollectionName = "leases")] IReadOnlyList<Record> leads,
FunctionContext executionContext,
IRestClient client)
{
// do stuff...
}
The end result would hopefully be that the binding fields (below) can be configured through the configuration blade:
PS: I've seen a few questions very close to this, but aren't dealing with the binding attribute issue.
All Functions binding (Cosmos, Storage, EventHub, etc) are governed by the same replacement mechanics for the values in the configs, also known as the binding expressions.
Normally the local.settings.json file is not pushed/published, because it's local to the environment.
You could, in your DevOps pipeline, have Environment Variables that override the local.settings.json values for example.
The article you link is initializing the config like so:
builder.ConfigurationBuilder
.AddJsonFile(Path.Combine(context.ApplicationRootPath, "appsettings.json"), optional: true, reloadOnChange: false)
.AddJsonFile(Path.Combine(context.ApplicationRootPath, $"appsettings.{context.EnvironmentName}.json"), optional: true, reloadOnChange: false)
.AddEnvironmentVariables();
So if you define an Environment Variable in DevOps, you should be able to override whatever is defined in the json file.