Please see the ReadMe for an overview of this project.
The main concept in this library is the ScriptHost. The ScriptHost is responsible for loading one or more function script files (either Node.js or C# files) along with a companion function.json metadata file, and bootstrapping those functions into a running Azure WebJobs SDK JobHost. Global host configuration options are specified in a host.json metadata file in the root of the scripts directory.
If you're familiar with JobHost and its use in a continuous WebJob console app, the hosting model for ScriptHost will be very familiar (ScriptHost is a subclass of JobHost):
static void Main(string[] args)
{
ScriptHostConfiguration config = new ScriptHostConfiguration()
{
// path to root function script directory
RootPath = Environment.CurrentDirectory
};
ScriptHost host = ScriptHost.Create(config);
host.RunAndBlock();
}
The ScriptHost expects a certain file layout. There should be an individual folder per function containing all the scripts and metadata for the function. Function folders can contain a single script, or multiple scripts (e.g. if the function is a Node module, includes companion files that it loads, etc.) Each function folder should also include a function.json metadata file describing the function, how it should be triggered, etc. See the sample referenced below for an example scripts directory.
In the sample directory there are example functions that can be run to see things in action. For some of the script types, there is additional configuration needed if you want to be able to run them locally. In Azure, all of the script types will run automatically.
Since our test matrix is very large with all the various script languages we support, it's unfortunately a chore to install all the things required to run all the end to end tests successfully. If you're going to be committing code you'll need to ultimately do this, but there are shortcuts (see below) if you just want to be able run a subset of the samples/languages.
First, here are the things you need to set up to run everything:
4.3.42(5)-release earlier version may not work)Item table with anonymous access (under "Easy tables"). Then add an AzureWebJobsMobileAppUri and AzureWebJobs_TestMobileUri environment variables that contain the URI of your Mobile App.createIfNotExists to true in those samples or manually create the ItemDb database and ItemCollection collection in your DocumentDB account.UseLocalFileSystem=true;Path=C:\Users\<user>\AppData\Local\Temp\DropBoxWhen running the samples you'll see output in the Console window, but it's recommended that you also open the WebJobs Dashboard to view your invocations. You can also use the Dashboard to replay/run functions, etc. To run the samples, you can use WebJobs.Script.Host or WebJobs.Script.WebHost. WebJobs.Script.WebHost is useful if you want to test WebHook samples (more details below).
To use samples with WebJobs.Script.Host as the startup project:
To use samples with WebJobs.Script.WebHost as the startup project:
If you don't want to set up all the languages, you can do one of the following:
host.json file. For example if you add a property functions: [ "QueueTrigger" ] it will only initialize/run that single function. You can add an array of functions to run here, omitting any you don't want.The sample includes a timer based scheduled job, so you will see the functions running and producing output in the console window and WebJobs Dashboard. The sample also includes Queue/Blob/WebHook functions that you can also trigger. Details on a few of the samples below.
0 * * * * *). Every minute, this function enqueues a message to queue samples-fsharp which in turn triggers _that _function to run.samples-workitems. Create this queue and add a message in the format { "id": 12345, "category": "Maintenance", "description": "Change the light bulb" }. The function will write the message to an output blob at path samples-workitems/{id} (where {id} is the id value of the message.samples-workitems. You can try this by writing a blob yourself. However, the above QueueTrigger function also writes its output to this container, so these functions are chained.samples-batch and writes the messages as output blobs to the samples-output container. It uses the same message format as above (expects an id property).images-original. The function resizes the image (using a companion exe), and writes the resulting resized image to blob container images-resized. The output binding binds to the name of the input blob and uses the same name for the resized image blob.You can run and test Azure Functions locally by running the WebJobs.Script.WebHost project. It is recommended that you use Visual Studio and add the following environment variables (or properties):
If the function app being used as part of the debugging setup is configured to used extension bundles. You would need to configured the following 2 things.
launch.json file:
host.json configuration in your function app:
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[4.*, 5.0.0)",
"downloadPath": "<newDirectory>"
}
}
newDirectory can be any path on your local machine. A set of files will be generated in this path.
Follow instructions on deploying the Functions runtime as a private site extension.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4