chore: add VS Code Azure Functions debug setup for gofuncapp - #9315
chore: add VS Code Azure Functions debug setup for gofuncapp#9315Fernadoteixeira wants to merge 6 commits into
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Azure Pipelines: 7 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
microsoft-github-policy-service
Bot
added
the
customer-reported
|
Thank you for your contribution @Fernadoteixeira! We will review the pull request and get back to you soon. |
|
Azure Pipelines: 7 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
There was a problem hiding this comment.
Pull request overview
Adds VS Code tooling for locally debugging the gofuncapp Azure Functions sample.
Changes:
- Adds Functions/Python debug settings and tasks.
- Adds relevant extension recommendations.
- Excludes
.venvfrom packaging.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
.vscode/extensions.json |
Updates recommended extensions. |
.vscode/launch.json |
Adds a Functions attach profile. |
.vscode/settings.json |
Configures the Functions workspace. |
.vscode/tasks.json |
Adds host and dependency tasks. |
cli/azd/test/functional/testdata/samples/gofuncapp/.funcignore |
Excludes .venv. |
Comments suppressed due to low confidence (2)
.vscode/tasks.json:29
- azd-code-reviewer: This second working directory has the same cross-platform separator problem. On macOS and Linux the pip task cannot resolve this path; use forward slashes here as well.
"cwd": "${workspaceFolder}/cli\\azd\\test\\functional\\testdata\\samples\\gofuncapp"
.vscode/settings.json:12
- azd-code-reviewer: The configured project is declared as
language: goin itsazure.yamland contains Go source, but this setting tells the Functions extension to treat it as Python. Align the Functions language/model settings with the Go worker, or point the entire setup at the Pythonfuncappsample instead.
"azureFunctions.projectLanguage": "Python",
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Comments suppressed due to low confidence (1)
.vscode/tasks.json:11
- [azd-code-reviewer] This directory is not directly runnable by Core Tools: the fixture intentionally stores its module as
go.mod.txt/go.sum.txt, and the functional test renames them only after copying the sample (up_test.go:256-258).func host startrunsgo build .in this cwd, so this pre-launch task cannot build the worker from a clean checkout. Add a preparation step that creates usable module files (or debug a prepared copy) before starting the host.
"cwd": "${workspaceFolder}/cli/azd/test/functional/testdata/samples/gofuncapp"
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (2)
.vscode/tasks.json:14
- azd-code-reviewer: Copying the module files into this source fixture leaves a nested
go.modin the repository.cli_test.go:830embedstestdata/samples/*, andup_test.go:256deliberately keeps these files as.txtto avoid that module boundary; after one debug session, functional tests/builds can fail until contributors manually remove the generated files. Prepare a disposable copy outside the embedded fixture (and point both tasks/settings at it), rather than mutating the fixture in place.
"command": "[ -f go.mod ] || cp go.mod.txt go.mod; [ -f go.sum ] || cp go.sum.txt go.sum"
},
"linux": {
"command": "[ -f go.mod ] || cp go.mod.txt go.mod; [ -f go.sum ] || cp go.sum.txt go.sum"
.vscode/tasks.json:24
- azd-code-reviewer: The sample has no
local.settings.json, and this task does not set a worker runtime. Current Core Tools therefore enters its worker-runtime selection prompt instead of starting the host, so the background pre-launch task is not reproducible and may wait indefinitely for input. Supply the native Go runtime in the task environment (or create an equivalent ignored local settings file during preparation).
"command": "host start",
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add a cleanup task that removes go.mod/go.sum from the gofuncapp fixture after each debug session to prevent functional test build failures. Wire it as postDebugTask in the Go Functions attach profile. Remove deploy-only settings (deploySubpath, scmDoBuildDuringDeployment) and unrelated chat setting from workspace settings.json. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
.vscode/tasks.json:36
- azd-code-reviewer: The prepare task preserves an existing
go.mod/go.sum, but this cleanup task unconditionally deletes both files. Stopping the debugger can therefore delete contributor-created or customized module files that predated the session on every OS. Record which files the prepare task created (for example with marker files) and delete only those during cleanup.
"label": "cleanup gofuncapp debug",
"type": "shell",
"windows": {
"command": "cmd.exe /c \"if exist go.mod del go.mod & if exist go.sum del go.sum\""
Adds .vscode/cspell.yaml that imports the existing cspell.global.yaml, enabling the VS Code cspell extension to discover the workspace spell-check configuration automatically. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
@Fernadoteixeira please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
| "host": "127.0.0.1", | ||
| "port": 2345, | ||
| "preLaunchTask": "func: host start", | ||
| "postDebugTask": "cleanup gofuncapp debug" |
| } | ||
| }, | ||
| { | ||
| "label": "cleanup gofuncapp debug", |
jongio
left a comment
jongio
left a comment
There was a problem hiding this comment.
Ran this against a local checkout. Most of the earlier feedback looks addressed. A few things still open:
The Windows prepare and cleanup commands don't do what they read as. In cmd.exe both && and & get absorbed into the if body, so the second guard only runs when the first guard's branch is taken. I reproduced both failure modes locally.
.vscode/cspell.yaml does fill in the dangling cSpell.import that settings.json already had, but it imports cspell.global.yaml while CI lints root files with cspell.misc.yaml. That splits the editor from CI on files like SECURITY.md.
Two of the new settings.json entries change behavior for everyone working in this repo, not just people debugging this fixture.
On the overall shape: root .vscode/ is shared by every contributor and every subproject in the repo. Pinning it to one functional-test fixture path means anyone with the Functions extension installed gets azure-dev treated as a Go Functions project rooted at test data. Would a .vscode/ folder inside the gofuncapp sample, or a short section in CONTRIBUTING.md, get you the same workflow without the workspace-wide side effects?
| "label": "prepare gofuncapp debug", | ||
| "type": "shell", | ||
| "windows": { | ||
| "command": "cmd.exe /c \"if not exist go.mod copy /Y go.mod.txt go.mod >nul && if not exist go.sum copy /Y go.sum.txt go.sum >nul\"" |
There was a problem hiding this comment.
cmd.exe folds && into the if body, so this parses as if not exist go.mod ( copy ... && if not exist go.sum copy ... ). When go.mod already exists the whole line is skipped and go.sum never gets created, so func host start then fails on a missing checksum.
Line 36 has the same shape with &: if go.mod is already gone but go.sum is still there, go.sum never gets deleted.
I reproduced both on Windows. Wrapping each if in parens fixes the parse and keeps the current "don't clobber what I didn't create" behavior:
| "command": "cmd.exe /c \"if not exist go.mod copy /Y go.mod.txt go.mod >nul && if not exist go.sum copy /Y go.sum.txt go.sum >nul\"" | |
| "command": "cmd.exe /c \"(if not exist go.mod copy /Y go.mod.txt go.mod >nul) & (if not exist go.sum copy /Y go.sum.txt go.sum >nul)\"" |
Line 36 needs the same treatment: cmd.exe /c "(if exist go.mod del go.mod) & (if exist go.sum del go.sum)".
This is separate from the ownership question already raised on line 33.
| # Copyright (c) Microsoft Corporation. All rights reserved. | ||
| # Licensed under the MIT License. | ||
|
|
||
| import: ./cspell.global.yaml |
There was a problem hiding this comment.
CI lints root and docs files with cspell.misc.yaml (.github/workflows/cspell-misc.yml and magefile.go), and that config layers overrides on top of the global word list. Importing the global config directly here means the editor flags words CI accepts.
Checked locally: cspell lint SECURITY.md --config ./.vscode/cspell.yaml reports MSRC and msrc as unknown words, while --config ./.vscode/cspell.misc.yaml is clean. Same split on docs/specs/metrics-audit/audit-process.md.
| import: ./cspell.global.yaml | |
| import: ./cspell.misc.yaml |
| ], | ||
| "aspire.enableSettingsFileCreationPromptOnStartup": false | ||
| "aspire.enableSettingsFileCreationPromptOnStartup": false, | ||
| "azureFunctions.projectSubpath": "cli/azd/test/functional/testdata/samples/gofuncapp", |
There was a problem hiding this comment.
These three are committed workspace settings, so every contributor with the Functions extension installed gets azure-dev treated as a single Go Functions project rooted at a test fixture. The repo also has samples/funcapp, so picking gofuncapp here is arbitrary for anyone not working on this specific sample.
Could these move into a .vscode/ folder inside the gofuncapp sample? That keeps the config next to the thing it configures and off everyone else's workspace.
| "azureFunctions.projectSubpath": "cli/azd/test/functional/testdata/samples/gofuncapp", | ||
| "azureFunctions.projectLanguage": "Go", | ||
| "azureFunctions.projectRuntime": "~4", | ||
| "debug.internalConsoleOptions": "neverOpen" |
There was a problem hiding this comment.
This applies to every debug session in the repo, including the existing "Debug azd cli" config, so anyone debugging azd stops getting the debug console. internalConsoleOptions is valid as a per-configuration attribute, so it can live on the new Go Functions entry in launch.json instead of here.
| "configurations": [ | ||
| // If you set `AZD_DEBUG=true` in your environment, `azd` will pause early in start up and allow you to attach | ||
| // to it. Use the Attach to Process configuration and pick the corresponding `azd` process. | ||
| { |
There was a problem hiding this comment.
This drops the comment that explained AZD_DEBUG=true, which is how you get azd to pause at startup so "Attach to Process" has something to attach to. That isn't discoverable from the config itself. The comment above "Debug azd cli" was removed too. Can both go back? They're unrelated to the Functions work.
| @@ -0,0 +1 @@ | |||
| .venv No newline at end of file | |||
There was a problem hiding this comment.
.venv is a Python virtualenv directory and this is a Go sample, so it won't match anything here.
azd uses .funcignore as the packaging ignore file for function apps (cli/azd/pkg/project/service_target.go:144), so this is an edit to a functional-test fixture rather than contributor tooling, which sits awkwardly with "does not change azd runtime behavior" in the description. Is it needed at all? None of the other samples ship one.
| "golang.go" | ||
| ] | ||
| } | ||
| } No newline at end of file |
There was a problem hiding this comment.
This drops the trailing newline on a file that otherwise had one. tasks.json and the new .funcignore don't have one either. Worth adding back so the diff stays to the intended change.
jongio
left a comment
jongio
left a comment
There was a problem hiding this comment.
Went back with Core Tools installed to check whether this debug flow actually runs end to end. It doesn't get as far as attaching, and the fixture cleanup has a gap that can leave cli/azd/test/functional in a state where it won't compile. Both inline.
My earlier notes on the Windows cmd.exe quoting, the cspell import target, and the workspace-wide settings still apply, so I won't repeat them here.
| { | ||
| "type": "func", | ||
| "label": "func: host start", | ||
| "command": "host start", |
There was a problem hiding this comment.
I installed Core Tools 4.5.0 and ran func host start against a copy of this fixture with go.mod/go.sum copied in exactly the way the prepare task does. It never starts the host, it stops on an interactive prompt:
Use the up/down arrow keys to select a worker runtime:
1. dotnet (isolated worker model)
2. dotnet (in-process model)
3. Node
4. Python
5. Powershell
6. Custom
Two things behind that. The fixture has no local.settings.json, so FUNCTIONS_WORKER_RUNTIME is unset and Core Tools falls back to asking. And there's no Go entry in that list. Go runs through Custom, which needs a customHandler block in host.json with a defaultExecutablePath plus a build step to produce the binary, and gofuncapp/host.json only carries version and extensionBundle.
As a preLaunchTask with isBackground: true that prompt never gets answered, so the task hangs, Delve never listens on 2345, and "Attach to Go Functions" has nothing to attach to.
Did this launch for you locally? If it did, knowing your Core Tools version would help, because it doesn't on 4.5.0. Otherwise this needs a local.settings.json with the worker runtime plus host.json and build wiring for the Go worker before the profile can do anything.
| "command": "host start", | ||
| "problemMatcher": "$func-golang-watch", | ||
| "isBackground": true, | ||
| "dependsOn": "prepare gofuncapp debug", |
There was a problem hiding this comment.
dependsOn means this task creates go.mod in the fixture, but cleanup only runs as postDebugTask on the launch config. Anything that runs this task without a debug session leaves the file behind: picking "func: host start" from Run Task, the Functions extension starting the host on its own, or terminating the task instead of stopping the debugger.
That matters more than it looks. With go.mod present:
$ go vet ./test/functional/
test\functional\cli_test.go:830:12: pattern all:testdata/samples/*: cannot embed directory testdata/samples/gofuncapp: in different module
The whole functional test package stops compiling until someone deletes it by hand, which is what the .txt suffix at up_test.go:256 exists to prevent. A leftover go.sum is harmless on its own, I checked that separately, it's go.mod that breaks the build.
cli/azd/test/functional/testdata/samples/.gitignore only carries .azure/ today, so these also show up as untracked files and can get committed by accident. Listing go.mod and go.sum there would cap the blast radius however the task gets invoked. Copying the sample to a temp dir and debugging from there would avoid the problem outright.
jongio
left a comment
jongio
left a comment
There was a problem hiding this comment.
Re-checked against d00ac9e. No new commits since my last pass, so the open items still stand. Two things I dug into that add to them.
The prepare and cleanup tasks aren't symmetric in when they run, and combined with the host start problem that isn't a corner case. Details inline.
On moving this next to the sample instead of the repo root: cli/azd/test/functional/testdata/samples/funcapp/.vscode/extensions.json already exists, so per-sample .vscode is an established pattern here rather than something new I'm asking you to invent.
Also relevant to who this is for: gofuncapp isn't referenced anywhere in the repo. copySample is called with funcapp at up_test.go:170, but never with gofuncapp, and a case-insensitive search for the name across the tree turns up nothing outside this PR. The fixture came in with #8599. So today the audience is whoever is hand-testing Go Functions support, which argues for keeping the config out of every contributor's workspace.
One thing to not chase: the bicep-lint failure is a module restore problem (BCP190) in cli/azd/internal/scaffold/testdata, unrelated to your changes.
| "host": "127.0.0.1", | ||
| "port": 2345, | ||
| "preLaunchTask": "func: host start", | ||
| "postDebugTask": "cleanup gofuncapp debug" |
There was a problem hiding this comment.
postDebugTask only fires when a debug session ends, and preLaunchTask gates whether that session ever starts. func: host start carries dependsOn: prepare gofuncapp debug, so the order on a normal F5 is: write go.mod and go.sum into the fixture, start the host, then attach.
On the Core Tools version I tested, the second step never completes, it sits on the worker runtime prompt. No session means no postDebugTask, so the first F5 leaves go.mod behind and go vet ./test/functional/ stops compiling until someone deletes it by hand.
That makes this more than the startup-failure path already raised on this line. It's the path you get by following the config exactly as written. Cleanup hung off the debug lifecycle can't cover setup that happens before the session exists.
Copying the sample into a temp directory and pointing cwd there would leave the fixture untouched no matter where the flow stops.
Why
Contributors working on the
cli/azd/test/functional/testdata/samples/gofuncappfixture need a reproducible VS Code setup to debug the Go Azure Functions host locally with the sample's fixture layout.What changed
gofuncappsample path with cross-platform path separators.go.mod/go.sumfrom fixture.txtfiles and start the Functions host..funcignorein the sample to ignore.venvduring packaging.Notes for reviewers
This is scoped to contributor tooling for local debugging of the Go fixture sample. It does not change azd runtime behavior.