deislabs / duffle-vscode Goto Github PK

The Install and Upgrade commands need to provide a way for users to enter parameters. The user experience needs to be pretty smooth here because users don't want to wade through confirming default values for 70 different parameters, or to have to type 14 overrides perfectly with no way to undo except to back out the entire operation, or to enter the same values repeatedly every time they redeploy. Not to mention that we need to work within the very limited VS Code UI!

Per the duffle install --set-file switch.

I cannot right-click a bundle and delete it, though I can do other things with it. The KubeCon public version.

env:

• duffle version 70dc6f9
• Ubuntu 18.04
• duffle-vscode: 0.0.1, compiled and installed as a .vsix
• vs code: 1.26.1

For duffle repo list:

when we go to list the repos in VS code:

You can see that the icon for duffle doesn't appear in the left extension panel.

This needs to be quite smooth and transparent!

We had a completion provider for the old TOML/components build definition but didn't have time to rework it for 0.0.4. This issue tracks doing so!

duffle version 48dbf3c.
VS code sha: stru6dd050e

Testing with hellohelm, the creation of creds works, the install using creds works, but the uninstall of creds does not work; fails completely.

duffle on the command line has errors, but works. see cnabio/duffle#220. Interestingly, duffle returns exit code 0:

duffle uninstall hellohelm -c hellohelm                                                                                                                               ✔  4698  21:54:32
Executing uninstall action...
[== Hi Duffle user ==]
uninstall action
Error: could not get Kubernetes config for context "": Error loading config file "/root/.kube/config": couldn't get version/kind; json parse error: json: cannot unmarshal string into Go value of type struct { APIVersion string "json:\"apiVersion,omitempty\""; Kind string "json:\"kind,omitempty\"" }
Action uninstall complete for hellohelm


 🔋 15% (3:10)  echo $?                                                                                                                                                               ✔  4699  22:04:04
0

In Duffle, we switched validation names from ARM Template naming to JSON Schema naming, and included a few extras:

cnabio/duffle#660

Duffle PR cnabio/duffle#338 defaults CLI credentialset generation to interactive, where it prompts for each credential value. Once this lands, the VS Code extension needs to pass the new --no-prompt flag to override this behaviour and generate an (empty) credentialset which the user can then edit in the text editor.

(Alternatively, we could launch the interactive command in a terminal, but that feels like a slightly awkward UI - open to feedback though.)

cc @technosophos @bacongobbler

It would be good to validate parameter values per:

• required flag
• minValue/maxValue
• minLength/maxLength
• allowedValues (though this should be ruled out by selector UI)

The extension currently has a generic icon in the marketplace. It should have a gorgeous @flynnduism Duffle icon in glorious full colour.

Proposal is to be able to browse to a live resource in Azure and extract its ARM template to a CNAB component. Though the template download is likely to be a feature of the Azure extension rather than the Duffle extension. What we can do though is provide a convenient way to expose ARM template parameters as CNAB bundle parameters. (These are defined for bundle.json but not for duffle.toml...)

• Issue Type: Performance
• Extension Name: duffle-vscode
• Extension Version: 0.3.0
• OS Version: Windows_NT x64 6.1.7601
• VSCode version: 1.38.1

Find more details here: https://github.com/Microsoft/vscode/wiki/Explain:-extension-causes-high-cpu-load

Need a New Project command which creates:

• duffle.toml
• bundle.json (or not? I am still not clear if this is an output)
• a simple app directory for the invocation image, e.g. using Butcher's run.sh template

The Create Project templates need to be updated as follows:

• Create duffle.json instead of duffle.toml
• New build definition schema TBA
• Dockerfiles should copy themselves to /cnab/build/Dockerfile not /cnab/Dockerfile

macos, after deleting the -cnab directory in the same place we now choose to recreate the -cnab directory for generating the installer.

👋 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! ❤️

We would like to get a feeling for what people are using the extension for, and how successful they are with it. So it would be good to have the following telemetry:

• Which commands are run
• For the Install command specifically, whether the install completed successfully or failed (as far as we can tell)

This requires an update to the README disclosing what telemetry we gather and how to opt out.

That villainous @bacongobbler is going to stop us using crazy illegal credentialset names that wreck the system (cnabio/duffle#504). Since the extension credentialset code dates from the BeforeTime, we are probably now using crazy illegal credentialset names all over the place. Let's fix this before the Canadian politely asks again.

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!

If a bundle doesn't run with the default driver, then the Install Bundle command fails. We need to offer a way to install a bundle using an appropriate driver, without bothering the user with 'what driver do you want to use' prompts in the 90% case.