Open asilverman opened 1 year ago
Review tracing to make sure it's helpful for customers
Am currently fighting an issue where for whatever reason, BICEP is hanging when called from New-AZDeployment in pwsh core, resulting in no output arm template and a hung process. These debugging flags appear undocumented save for a few search hits saying that they exist, and a procmon trace isn't showing where the outputs go to. The procmon call stack indicates nothing either. How can I capture any output stream - if in fact that's where they go - during the BICEP compilation stage when called via powershell?
Works fine in PS5.1 and this has all come about since MS broke Az.Resources with Constrained mode in 7.4.0 and I had to roll back to 7.3.9 (see https://github.com/PowerShell/PowerShell/issues/20785)
So yes, please provide more information on how this debugging is supposed to work and be captured/output in vscode.
I agree we can do a better job of emitting tracing (and documenting what is possible today). That being said, can you file a separate issue for the specific item that is failing with repro steps? Or is that what https://github.com/PowerShell/PowerShell/issues/20785 is covering?
Hi @alex-frankel
Sorry for delay, didn't get a notification about your response. I'd like to provide a fuller issue with repro steps, but I'm having trouble finding anything meaningful in the logs that might be useful for you. If you could perhaps suggest something I could enable that might trap the call to bicep, and show the hang, I could look into that?
@lansalot have you managed to get a workaround working for this while waiting for the issue is resolved?
@lansalot have you managed to get a workaround working for this while waiting for the issue is resolved?
Nope, I had to fall back to 7.3.9. Too much work to do. Is BICEP hanging for you too then? Same thing, creates the temp output folder, but nothing in it, yet fine from command line?
Yes getting the same issue; bicep just hangs when called and nothing in the output folder. Seems to work if using bicep directly
@lansalot have you managed to get a workaround working for this while waiting for the issue is resolved?
Nope, I had to fall back to 7.3.9. Too much work to do. Is BICEP hanging for you too then? Same thing, creates the temp output folder, but nothing in it, yet fine from command line?
so PS 7.3.9 is working for you then? I tried that but still seemed to hang although I didn't try a simpler deployment
@lansalot have you managed to get a workaround working for this while waiting for the issue is resolved?
Nope, I had to fall back to 7.3.9. Too much work to do. Is BICEP hanging for you too then? Same thing, creates the temp output folder, but nothing in it, yet fine from command line?
so PS 7.3.9 is working for you then? I tried that but still seemed to hang although I didn't try a simpler deployment
Ah no, it still hangs on 7.3.9 too - getting my issues mixed up there, got about 3 open !
@lansalot : I had to get a deployment working, I last did one around feb so this combo worked if it is any use for you; I'm sure the issue will have appeared somewhere later in the releases but I just needed to get something done:
Component | Date | Version |
---|---|---|
PowerShell Core | 2023-02-23 | 7.2.10 |
Azure CLI | 2023-02-07 | 2.45.0 |
Bicep | 2023-02-08 | 0.14.46 |
MS Graph Module | 2023-02-16 | 1.22.0 |
AZ Module | 2023-02-07 | 9.4.0 |
Is your feature request related to a problem? Please describe. There is a lack of visibility regarding the actions that are being taken both by the Bicep extension for vs code as well as the operations executed by the bicep CLI. As a direct consequence troubleshooting is much harder since it requires more in-depth understanding of the code execution and development expertise to reverse engineer the flow of control being done by the extension/cli
Describe the solution you'd like We should enable a
verbose
setting and flag for extension and cli so that debug logs are available for users when they need to troubleshoot. Debug logs would contain amongst other things the current directory of execution and the steps being executed by the system processing of the Bicep manifestsAdditional Info
Related to discussion in https://github.com/Azure/bicep/issues/9902