We've had multiple customers fail to deploy because they selected "Deploy to Function App" from the wrong sub folder of a project. This hopefully fixes that in two ways:
1. Use "azureFunctions.deploySubpath" instead of the folder they select. Users will get a warning.
1. If there is only one workspace folder open and the deploySubpath setting is not an empty string - just use that path without prompting the user at all.
C# already has "deploySubpath" set on new projects. I modified Python and JavaScript to also set it.
The tags are changing when v2 GA's soon. We could hard-code the new strings and try to time our release perfectly with the func cli, but I'd rather dynamically check the dist-tags.
I'm basically shifting the implementation of the problem matcher from each user's project to our extension. This means we can change/improve it in the future without having to modify the user's project.
Unfortunately, the func cli is very annoying to parse, so I only added support for one error (although it's somewhat common).
I incorrectly made the assumption that `vscode.tasks.taskExecutions` was the list of _running_ tasks, but it's actually a list of tasks that have _ever_ run in this session, even if they're not running right now.
As described in this PR: https://github.com/Microsoft/vscode-azurefunctions/pull/558, we have to get the inner 'func' process on Windows instead of attaching to the parent PowerShell process. Well it turns out there's a delay between when the PowerShell process is created and when it has the child process running the func cli. This change prevents us from attaching to the PowerShell process and getting "unverified" breakpoints.
We've had a whole host of issues related to pickProcess for C# debugging. I was able to simplify this logic by leveraging VS Code's tasks api that was released a few months ago rather than searching the entire list of processes myself. The VS Code tasks api actually gives me the pid of the task, which is great.
Unfortunately it's never that simple, though 😅 On Windows, it gives me the pid of the parent PowerShell process, not the actual func process. In order to find the child process, I decided to leverage the windows-process-tree module that's created for and shipped with VS Code, which is a native windows module and avoids a lot of the problems we originally ran into with wmic (which most other modules like 'ps-node' use).
Users need to run `func extensions install` before debugging or deploying on JavaScript projects. This was always the case for some triggers (that we didn't "officially" support in VS Code), but it wasn't required on blob/queue triggers until the most recent functions release. Hence why we're adding this now.
As part of this change, I made the C# 'preDeploy' logic more generic so that it would also cover the JavaScript `func extensions install` case. I also changed the C# logic so that it won't run for local git deployments, since that should be covered by kudu.
Create and locally debug Python functions projects. Option to create is still hidden as Python is still in preview and we are working on the deployment scenario.
In order to debug, `python -m pip install --pre ptvsd` must be run within the project's virtual environment. There is also a dependency on the experimental Python Extension, but they should release on Tuesday, 9/5/2018.
Stephen Weatherford (MSFT)
Eric Jizba
Nathan
Hanxiao Liu