* Fix dependency management background logs
* Use log level in RpcLogger.WriteSystemLog
* Format "System Log" messages as a single line
* Don't share StringBuilder in RpcLogger
* Rename isUserLog parameter to isUserOnlyLog
* Move isUserOnlyLog parameter to the first position and make it mandatory
* Add isUserOnlyLog parameter comment
* Improve module version purge on managed dependencies auto-upgrade
* Purge dependency snapshots regardless of whether a new snapshot will be installed or not
Fixed issue:
If a PowerShell function invokes Push-OutputBinding and then throws an exception, the next invocation response contains data passed to Push-OutputBinding on the previous invocation.
* Add UsingManagedDependencies function
* Extract GetHttpTriggerResponse method
* Enable manaded dependencies in TestFunctionApp\host.json
* Output Az path from UsingManagedDependencies
* Add InvokeHttpTrigger overload returning the response string
* Add ManagedDependenciesEndToEndTests
* Add new line to ManagedDependenciesEndToEndTests.cs
* Fixing faulty logic in InstallFunctionAppDependencies and refactoring DependencyManager.cs to accommodate for unit test.
* Adding unit test to validate the retry logic in InstallFunctionAppDependencies as well as a successful module download.
* Adding Save-Module number of attempts to error log. Updating unit test to reflect this change.
* Adding logic to dependency manager to fail in the first dependencies installation run if the PSGallery could not be reached, but continue if previous dependencies exist.
* Adding unit test to validate that a function app execution should continue if the PSGallery could not be reached but a previous installation of managed dependencies exists.
This is to fix the regression in local debugging.
We create the first `PowerShellManager` instance when processing the first `FunctionLoad` request, so the debugger has the target Runspace to attach to.
However, we delay the initialization of the first `PowerShellManager` instance until the first invocation (when checking out the instance from pool).
It turns out we cannot have the dependency manager to create a separate Runspace for downloading.
The VS Code local debugging assumes the target `Runspace` has `Id = 1`, which was true before as only one Runspace will be created initially.
Now, the dependency manager creates a separate `Runspace` for downloading, and there will be a race condition -- sometimes the `Runspace` created for the downloading has `Id = 1`, and thus the debugger will attach to that Runspace, which will be reclaimed after the download and causing the `Wait-Debugger` in the user's function script to not be hit.
This refactoring makes sure only one `Runspace` is created initially -- the `PowerShell` instance used for the downloading is also used to serve the first invocation request.
So there is no race condition and local debugging can work reliably.
- Change how `Push-OutputBinding` supports pipeline input: `<# produce values #> | Push-OutputBinding -Name queue`
- Change `Push-OutputBinding` to take advantage of the output binding data shared by the worker, to have the `Singleton` and `Collection` behaviors correspondingly.
When script from the helper module is running, it can use `[FuncMetadata]::GetOutputBindingInfo([Runspace]::DefaultRunspace.InstanceId)` to get the output binding info about the function that is currently running. Hence, `Push-OutputBinidng` can do smart things based on the `-Name` with this change.
* Add e2e test suite from java worker
* add to appveyor for CI
* remove Invoke-Test for e2e
* move test csproj
* fix path in module tests
* change to capital T
* uppercase another T
* delete extensions.csproj
* add silentlyContinue to Remove-Item
* props file is one directory up
Anatoli Beliaev
Tyler James Leonhardt
Francisco Gamino
Dongbo Wang
SatishRanjan