It fails with error:
error: unknown switch `U' usage: git remote add [] -f, --fetch fetch the remote branches --tags import all tags and associated objects when fetching or do not fetch any tag at all (--no-tags) -t, --track branch(es) to track -m, --master master branch --mirror[=(push|fetch)] set up remote as a mirror to push to or fetch from

For the first time, git installed user, the extension will give the following error while committing the workflow file:

"Commit failed due to error: fatal: LF would be replaced by CRLF in .github/workflows/workflow.yml"

It has two solutions:

1. The user runs below command to enable git to convert CRLF to LF
   git config --global core.safecrlf false

2. Our extension should convert the workflow file to the Unix format. In javascript we can run
   the_string.replace(/\r\n/g, "\n"); to convert to LF

• Issue Type: Performance
• Extension Name: azure-deploy
• Extension Version: 1.0.5-pr-75-5e64aa7
• OS Version: Darwin x64 19.4.0
• VSCode version: 1.44.0

⚠️ Make sure to attach this file from your home-directory:
⚠️/Users/vineetmimrot/ms-vscode-deploy-azure.azure-deploy-unresponsive.cpuprofile.txt

Find more details here: https://github.com/microsoft/vscode/wiki/Explain-extension-causes-high-cpu-load
ms-vscode-deploy-azure.azure-deploy-unresponsive.cpuprofile.txt

Tried deploying a .NET 5 Application to App Service and got the following error

Pipeline provisioning job failed with error: 'Error=Failed to render: Evaluation error: Helper 'beginsWith' called with wrong number of arguments, needed 5 but got 0 Current node: Expr{Path:Path{Original:'beginsWith', Pos:3}, Pos:0}, Message=Mustache parsing failed'

No other errors in logs

Here is a repo to test

https://github.com/isaacrlevin/.NET-Conf-Demos/tree/main/AppService

👋 Hi there, Martin here, from the VS Code team.

Recently we've announced the Remote Repository feature that lets you browse and edit files and folders directly on GitHub.

Open Remote Repository... opens VSCode on a folder or workspace located on a virtual file system. We call this a virtual workspace. We observed that not all extension support this well, either because they can not, or they haven't thought about it.

It would be fantastic if you could test whether your extension can handle virtual workspaces:

Check out the Virtual Workspaces Extension Author Guide on how to do that.

When done, set the new virtualWorkspaces capability in your 'package.json'.

{
  "capabilities": {
    "virtualWorkspaces": true | false
  }
}

• Use "virtualWorkspaces": true if your extension is prepared for virtual workspaces
• Use "virtualWorkspaces": false if your extension should be disabled when a virtual workspace is opened

For questions and comments please use the Virtual Workspaces Tracking Issue.

Thanks for the support and the great work! ❤️

Event triggered by: vineetmimrot
Workflow: Extension Test analysis
Branch: refs/heads/e2e-test

Something went wrong with GitHub checks for Extension Test analysis. For more info visit-

https://github.com/microsoft/vscode-deploy-azure/actions?query=workflow%3A%22Extension%20Test%20analysis%22%20is%3Afailure

https://dev.azure.com/vineetpc/AspNetWebApp/_build/results?buildId=706&view=results

If the branch on which the pipeline is configured has non alphabetic characters, then the trigger doesn't work as the mustache renderer changes while html escaping them.
Hence it gets converted like this in azure-pipelines.yaml:
orignal branch name: users/hiyada/bugFile
converted branch name: users/hiyada/bugFile

When I go through the workflow, I am stopped here

The list is blank, even though the api is returning a list per fiddler

Let me know if there is additional telemetry you need

Hello 👋 I'm from the VS Code team.

Recently, we have been exploring a security feature we refer to as Workspace Trust. This feature is intended to centralize and unify a security conscious decision required by a variety of VS Code features. With workspace trust, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.

Why you should care

Your extension is incredibly popular with VS Code users! We want to make sure that those users have a delightful experience with workspace trust and that includes extension authors deciding how much of their extension is supported in an untrusted workspace.

Workspace Trust experience

You can enable the feature with the following setting security.workspace.trust.enabled. Once enabled, you will see the following dialog when opening folders in VS Code.

This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the setting security.workspace.trust.startupPrompt.

You can follow the development of Workspace Trust and provide feedback in issue #106488.

Workspace trust API

First off, all of what I am about to say can be found in issue #120251. That issue will include discussion of the feature and any updates to the feature.

The Workspace Trust extension API is now in stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.

You can declare your extension to provide complete, partial or no support in untrusted workspaces using the untrustedWorkspaces capability in package.json.

The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": true
  }
}

The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": false
  }
}

The third option is to declared limited support. There are three tools provided to you when you select the limited option.

First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using restrictedConfigurations array property in untrustedWorkspaces object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code Workspace Configuration API.

The following example declares the settings that are restricted in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": "limited",
    "restrictedConfigurations": [
      "markdown.styles"
    ]
  }
}

Next, you can also check and listen if the current workspace is trusted or not programmatically using the following API:

export namespace workspace {
  /**
   * When true, the user has explicitly trusted the contents of the workspace.
   */
  export const isTrusted: boolean;
  /**
   * Event that fires when the current workspace has been trusted.
   */
  export const onDidGrantWorkspaceTrust: Event<void>;
}

Lastly, you can hide commands or views declaratively with the isWorkspaceTrusted context key in your when clauses.

A far more detailed guide on how to onboard which will be updated as we receive feedback can be found in issue #120251.

Rollout plan

Workspace Trust will remain disabled for the month of May, but we are planning on enabling this by default in the future. To prepare for that day, we would love for you to try it out and provide feedback.

We'd love your feedback

Since this issue was created in an automated fashion, we won't be monitoring the responses in this issue (our notifications would explode!). Instead we ask you to drop questions, and feedback in issue #120251 as we've mentioned above.

We're excited to see what you do with workspace trust!

@bishal-pdMSFT @kanika1894 Can we ask all the repo details first and then ask Azure details like Subscription. Currently it is mixed and match. 1st subscription then github pat then azure resource details etc

Casually checking in 😃
Happens after logging in to Azure

This repo is private. However the blog post (https://azure.microsoft.com/en-us/blog/new-deploy-to-azure-extension-for-visual-studio-code/) and marketplace page (https://marketplace.visualstudio.com/items?itemName=ms-vscode-deploy-azure.azure-deploy) contain links to this repo. These only work for authorized Microsoft internal users. Anonymous or non-authorized users get a 404 error.

Steps to reproduce:
Use a browser that is not signed in to GitHub (anonymous) or signed as a user without access to the Microsoft org.

Suggested fix:
Open up the repo (or remove the public links)

Hi! Please note that this extension is being deprecated and will be removed from VS code marketplace on 11 April 2022.

This also means that "Configure CI/CD Workflow" and "Browse CI/CD Workflows" option will no longer be available on Azure Kubernetes Service extension.

Please move your workloads away from the extension before 11 April 2022.

As an alternative, you may choose to use Starter workflows from GitHub to quickly onboard your application to GitHub Actions. You may alternatively choose to use Create file API to create a Actions workflow file and Secrets API to create pre-requisites deployment secrets.

Description-
Template service has been updated with python support for linux web app.
PR link
vs code-deploy-azure repo was configured locally to fetch the newly added template for python locally. Using these changes
the template got fetched and was committed to repo successfully. But after the workflow gets committed oryx build manifest files are also getting added to the web app folder structure. These files are not being added by workflow run and also cause the run to fail.

Steps -

• Run template service locally
• Run provisioning service locally
• configure vscode-deploy-azure repo with given patch link to patch
• Build and run vs code repo and use deploy to azure option -"command+shift+p"
• select a python repo- sample repo
• from the list of template options select "Python to App Service" (the newly added template in template service)
• select rest options as required. python version(select any), startup command(default empty)
• the workflow gets committed succsessfully.
• Check the web app folder structure by hitting the url of the web app.
• We can see extra files being added to the structure which are not being caused by workflow.
• To confirm that this is not a workflow issue and vs code specific issue following steps were taken
  -> The workflow in template service was shortened to just checkout action. Expectation here is that it won't run anything and app folder will be empty.But still these files were being added after committing.video link
  -> the same process was done using postman where workflow was fetched and committed by making call to provisioning service apis. In this case workflow got committed as before and also no extra files were added .

We suspect that vs code is tweaking some properties in web app causing these files to be added .This requires More investigation.

• Issue Type: Bug
• Extension Name: azure-deploy
• Extension Version: 1.2.2
• OS Version: Windows_NT x64 10.0.19042
• VSCode version: 1.54.2

⚠️ We have written the needed data into your clipboard. Please paste! ⚠️

• Issue Type: Bug
• Extension Name: azure-deploy
• Extension Version: 1.2.2
• OS Version: Windows_NT x64 10.0.19041
• VSCode version: 1.54.3

⚠️ We have written the needed data into your clipboard. Please paste! ⚠️

Hello, teams.

I think this extension is very helpful and nice.

I've been trying to configure "Deploy to Azure Configure CI/CI Pipeline"
After choosing the target of Azure subscription and web app, I can't proceed at all.
Any organization of my Azure DevOps can't accept like below.

• My Azure DevOps Organization : https://dev.azure.com/zerobig-devops/

I've tried another organization also, but the result was the same.
How can I solve this issue?

Hello 👋 I'm from the VS Code team.

Recently, we have been exploring a security feature we refer to as Workspace Trust. This feature is intended to centralize and unify a security conscious decision required by a variety of VS Code features. With workspace trust, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.

Why you should care

Your extension is incredibly popular with VS Code users! We want to make sure that those users have a delightful experience with workspace trust and that includes extension authors deciding how much of their extension is supported in an untrusted workspace.

Workspace Trust experience

You can enable the feature with the following setting security.workspace.trust.enabled. Once enabled, you will see the following dialog when opening folders in VS Code.

This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the setting security.workspace.trust.startupPrompt.

You can follow the development of Workspace Trust and provide feedback in issue #106488.

Workspace trust API

First off, all of what I am about to say can be found in issue #120251. That issue will include discussion of the feature and any updates to the feature.

The Workspace Trust extension API is now in stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.

You can declare your extension to provide complete, partial or no support in untrusted workspaces using the untrustedWorkspaces capability in package.json.

The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": true
  }
}

The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": false
  }
}

The third option is to declared limited support. There are three tools provided to you when you select the limited option.

First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using restrictedConfigurations array property in untrustedWorkspaces object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code Workspace Configuration API.

The following example declares the settings that are restricted in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": "limited",
    "restrictedConfigurations": [
      "markdown.styles"
    ]
  }
}

Next, you can also check and listen if the current workspace is trusted or not programmatically using the following API:

export namespace workspace {
  /**
    * When true, the user has explicitly trusted the contents of the workspace.
    */
  export const isTrusted: boolean;
  /**
    * Event that fires when the current workspace has been trusted.
    */
  export const onDidGrantWorkspaceTrust: Event<void>;
}

Lastly, you can hide commands or views declaratively with the isWorkspaceTrusted context key in your when clauses.

A far more detailed guide on how to onboard which will be updated as we receive feedback can be found in issue #120251.

Rollout plan

Workspace Trust will remain disabled for the month of May, but we are planning on enabling this by default in the future. To prepare for that day, we would love for you to try it out and provide feedback.

We'd love your feedback

Since this issue was created in an automated fashion, we won't be monitoring the responses in this issue (our notifications would explode!). Instead we ask you to drop questions, and feedback in issue #120251 as we've mentioned above.

We're excited to see what you do with workspace trust!

Does not access github. No logs. No feedback.
PAT key copied from Github and entered when requested by extension.
"Analyzing your repository" hanging forever.
Doesn't access Github using the key. Key never used.
What's the problem?
Documentation wrong?
It seems this extension doesn't work as intended.

Thanks

When deploying an Angular App to Azure (using the 'Deploy to Azure' extension), a setting ('domainApi', in the below environments file) is not being used whenever its accessed in the app.

export const environment = { production: true, domainApi: 'https://myapi.azurewebsites.net' };

It's being replaced with the url of the app im deploying to Azure (i.e. mysite.azurewebsites.net), so im getting a 404 as the apis are on myapi.azurewebsites.net, not mysite.azurewebsites.net. No where in my code do i do this

Could anyone please suggest how I get the Angular app to retrieve the correct setting from the environment.ts file?

Note, the settings in all the enviroments are the same so its not being overwritten by another environments file.

Thanks in advance.

seems the YAML parser is conflicting with the https://github.com/redhat-developer/vscode-yaml extension. Who needs to fix this?

Looking at the templates for Github Actions it looks like there aren't templates for .NET. It would be great to have this as non-Windows .NET devs don't have options to generate workflows (you can do this for Visual Studio in Windows)

Hi,

from looking into your repository it looks like you use the yaml language server directly rather than relying on VSCode-YAML for the YAML support. I was wondering if there is any particular reason why you spawn up the language server yourself, rather than just using VSCode-YAML as an extension dependency and having that spawn it. If you are doing this because there are some API's missing that you need then please let me know.

The only reason I bring this up is this has been done before and it will eventually lead into multiple language servers running for a yaml file if the user has vscode-yaml and this extension installed. This can create several unintended results like duplicate completions, etc etc.

Couldn't get repository details. Ensure your repo is hosted on Azure Repos or GitHub.

https://dataexplorer.azure.com/clusters/ddtelvscode/databases/VSCodeExt?query=H4sIAAAAAAAAA31TTU9qMRDd8ytqN0KiYuLSYPLCM083hniNLk29HbBa2mamBTHG3+4UvJcK17fsnI85004tREFRYYxmDmIk1Mz3z0714LxnGbmhVNdANE3239WDx9ep9Utm3arl5QJcpPtq7DVcvsXeh1g+A4KoABeAd+zGtvMgLrb2LWejqtjYeHetxcFIHJKfw72yCU6oqR+2Am4ALhdvVE45ElK9J4RjDcH6ldzycqhOzrD2bmpmuVCbWh8HE8AaB1kL2V2LgD4QDxcUEjy+kHf9CZcAowEabHkIwTN3YTQg06OniMbN+mv9SYkWohef0MHK6H1FCxX0OiHyKImAiSHFfdUu40dASrZDsqnvd6kihF8bEIOFhNIT1WhC5MfoGuYnXgibC1cWQelV+xwdHr9SCztA9Mg7RmoG+w4lOugNh81+/CfEp5ARE+/Dlr0zK2+pLOHy9g6M+xR9OX6G+vXaTZrlOpJjbhThj9O3qSgLOeHAzXnN4R5SHMm/hoJVq41Mt4pyiO/nzXGq/D1Bg5bnvR04DzRVxq6xzn/8BSuDxNX7AwAA

let starttime = ago(30d);
let NsuccessfulGHWorkflow = RawEventsVSCodeExt
| where ServerTimestamp > starttime
| where VSCodeSessionId != 'someValue.sessionId'
| where ExtensionName == "azure-deploy"
| where EventName == "azure-deploy/configure-cicd-pipeline"
| extend props = parse_json(Properties)
| extend repoprovider = tostring(props.repoprovider)
| extend journeyid = tostring(props.journeyid)
| extend currentuserinput = tostring(props.currentuserinput)
| extend result = tostring(props.result)
| extend currentStep = tostring(props.currentstep)
| extend subscriptionid = tostring(props.subscriptionid)
| extend pipelinealreadyconfigured = tostring(props.pipelinealreadyconfigured)
| extend errormessage = tostring(props.errormessage)
//| where pipelinealreadyconfigured =~ "true"
//| where subscriptionid != ""
//| where currentStep !in~ ("CheckInPipeline","CreateAndRunPipeline", "PostPipelineCreation" ,"DisplayCreatedPipeline")
| where result =~ "failed";
NsuccessfulGHWorkflow

@kanika1894 Please check this issue.