search

Azure / vscode-aks-tools

Visual Studio Code extension for Azure Kubernetes Service
MIT License
41 stars 50 forks source link

Consider how Draft state will be persisted #265

Closed peterbom closed 4 months ago

peterbom commented 11 months ago

Relating to #264 - ideally we'd want to retain state after the user closes the webview, so that the user wouldn't have to go through the trouble of re-selecting their ACR, image names and file locations (also allowing us to tell whether certain draft commands have been run based on the presence/absence of files in the workspace).

I don't think the standard persistence mechanisms for webviews are appropriate here, because state will vary on a per-workspace basis. I.e. if a user configures some Draft settings in one project, and then opens Draft in a different one, we probably wouldn't want to load the state from the last one.

The workspace-level settings (which will be populated under the .vscode folder) might be the right place for this, but need more investigation.

peterbom commented 10 months ago

Looking at the aks-devx-tools and Docker extensions, it appears that workspaceState would be a promising place for this.

Unlike the workspace-level settings which would be persisted in the .vscode folder, this state would be stored on a per-user basis. I think this would make sense for cluster and ACR information, but I'm not sure about the presence/absence of Dockerfiles and GH workflows, which really are a shared property.

Maybe it'd make sense to use workspace state for cluster/ACR configuration, and workspace-level settings for tracking whether/where Draft files have been created.

Although...I feel hesitant about the latter, which involves saving state somewhere that's going to be persisted in people's git repositories. Perhaps we can hold off on that for now, and see if we can programmatically determine where these files are, similar to how the docker extension does so. This would also be preferable for projects where these files have already been created, not necessarily using Draft.

peterbom commented 9 months ago

It appears that there are discussions around building some kind of state/configuration management that is decoupled from both the environment (VS Code, Portal, CLI) and tools (Draft and theoretical future integrations like Skaffold or AI tooling). A possibility is defining some kind of config file, but the approach is very speculative at the moment, and will require coordination between different teams.

This means there's a risk that if we build something that users will place under source control (like a settings file in the .vscode folder), it will end up competing with the approach used by other tools in future, resulting in confusion for users and us possibly having to create some kind of migration experience.

Because of this I'm leaning heavily towards keeping all the configuration purely in VS Code workspace-level state, which is tied to each user/machine and will not be added to users' source control.

We should do this with the understanding that the persistence mechanism might be swapped out with something completely different at a later stage, and design the Draft features accordingly, by decoupling the configuration from the tooling as much as possible.

This will allow us to move forward with the Draft migration without being blocked waiting for agreement from other teams on the best way to store the configuration, and once we've implemented these features, this extension can be used as a real-world use case for helping drive the requirements for the configuration mechanism.