As for node clicks, I think we should locate and use k8s tools commands that open those yaml config files when deployment nodes and others are clicked. This is different from expand/collapse toggle, and I find viewing those yaml configs in code editor helpful. That is before we add dedicated list/property views for out top level nodes.

Originally posted by @RandomFractals in #44 (comment)

similar to RedHat YAML ext. in #6

Also, see if k8s tools would automatically install kubectl and az for us, as those tools are required for Azure k8s cluster management.

list delivered features in changelog

for onboarding devs and devops using k8s, gitops, or related command line tools.

Walkthrough steps might include:

• short gitops intro
• links to CLI tools
• list of gitops commands
  ...

see docs: https://code.visualstudio.com/updates/v1_57#_new-getting-started-experience

background info on welcome pages: microsoft/vscode#63152

and walkthroughs: microsoft/vscode#119097

for editing cluster configs in .yml format

YAML vscode extension: https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml

Use content from flux2 repo for the intro section: https://github.com/fluxcd/flux2

List implemented features and maybe add a TODO section to highlight new features being worked on in Sprint 3.

We'll probably keep gitops terminal developed in #8

However, we'll need flux.ts that is more like kubectl CLI integration in k8s tools extension, with its own output channel to run some of the Flux CLI commands, capture their outputs, transform results and update our GitOps tree views.

See these k8s tools and gitops terminal notes for more info: #8 (comment)

This is required for integrating commands like flux reconcile for sources in #42 and deployments in #43.

We need to list Flux CLI dependency in docs to let devs and devOps install independently if desired, along with kubectl this extension depends on for most of its operations.

This is in addition to #27 that will check if Flux is installed to enable GitOps commands that rely on it.

Link it to Flux installation docs: https://fluxcd.io/docs/installation/

see changes in #24

There is probably more we should do there for our tree views data structure setup.

As a user, I want to be able to see a tree of resources that have been created by a specific Application of type Kustomization.

A Kustomization can effectively create any number of arbitrary objects as its children. These components may be any valid Kubernetes Kind or Custom Resource, even CRD themselves.

Because of this complexity, we will need to develop our full nested tree building functionality in multiple iterations, and each different Kind of object may require different commands to track it's children.

This ticket will focus only on the first level of resources created by any one specific Kustomization . Consider that a Kustomization may create objects across different namespaces, and it may create Namespaces as well.

Commands

Note:

• All immediate children to a Kustomization will have a specific label matching the name of the parent Kustomization, we will use that label to identify the immediately created objects (in other words, this method will not allow us to track children at any further level or recursion)
• The kinds of objects available in a cluster, besides "built-in" objects on native Kubernetes API, must be dynamically determined.

Step 1: Get a list of all available objects kinds in the cluster:

kubectl api-resources --verbs=list -o name

The above command will return a new-line separated list of all possible object Kinds available in the server, this list must be passed as a string of comma separated values to the following command.

Step 2: Get all resources that match the Kustomization label.

kubectl get {comma separated list of all lines returned by the command avobe} -l kustomize.toolkit.fluxcd.io/name={name of Kustomization} -n {namespace where Kustomization exists} -o json

For sample output please see the following Gist: https://gist.github.com/murillodigital/c96fb943a17a130c91bab8897cfc2079

Tree display / UI

• Each Application should allow for expanding a tree underneath showing the various objects that it created, in this iteration we will focus on the immediate first tier of objects created, as they can nest "infinitely".

• Each item returned by the get command in Step 2 above must be added as a child node to the applicable Kustomization following the syntax: (Namespace) kind: name. Using the sample output linked above as example, two children nodes would be added below the Kustomization:

(blue-ns) Service: hello-kubernetes-eks-ha
(blue-ns) Deployment: hello-kubernetes-eks-ha

• On click, the full object manifest should be loaded in the editor.

Note: Properties to display and action on hover is still undefined and outside the scope of this ticket.

Important Implementation Details

As stated, each Application may create any number of objects of any Kind, considering K8s CRD model, the Application may create new Kinds altogether that may be proprietary. Our implementation must be generic and abstracted enough to be able to display this level of diversity without having to hardcode specific properties or kinds of objects.

Why it's important

Both User Personas will have as utmost interest by using the Extension to have visibility into the health and deployment status of any and every resource they have declared in their desired state. Providing a complete view of all those resources is necessary to avoid confusion and misinterpretation of the status of a given deployment.

As a user, I want to quickly tell whether there's problems fetching from some source, and quickly see what the error message is.

Sources may run into problems trying to connect or fetch revisions. Following VS Code Extension guidelines, provide a quick visual cue to users if a source has entered a problem state, and allow the user quick access to see the error message (again following extension best practices, whether tooltip or otherwise.

A source will be in a problem state when the attribute status.conditions[0].status is False and the information required to be shown for error message is status.conditions[0].message and status.conditions[0].reason

Please refer to #40 for details on how to query for the payload below.

kubectl get gitrepository sample-k8s-not -o yaml
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"source.toolkit.fluxcd.io/v1beta1","kind":"GitRepository","metadata":{"annotations":{},"name":"sample-k8s-not","namespace":"default"},"spec":{"interval":"1m","ref":{"branch":"main"},"url":"https://github.com/murillodigital/sample-k8s-not"}}
  creationTimestamp: "2021-08-31T20:03:41Z"
  finalizers:
  - finalizers.fluxcd.io
  generation: 2
  name: sample-k8s-not
  namespace: default
  resourceVersion: "1318400"
  uid: 7b5c3be3-6028-4af0-86ec-70eecc76720e
spec:
  gitImplementation: go-git
  interval: 1m0s
  ref:
    branch: main
  timeout: 20s
  url: https://github.com/murillodigital/sample-k8s-not
status:
  conditions:
  - lastTransitionTime: "2021-08-31T20:03:52Z"
    message: 'unable to clone ''https://github.com/murillodigital/sample-k8s-not'',
      error: authentication required'
    reason: GitOperationFailed
    status: "False"
    type: Ready
  observedGeneration: 2

Currently, this is done on every activation of gitops extension.

See #8 and #35 for the initial flux pre checks we should run only once.

Convert kubernetesTools interface to a class with methods to access kubectlProvider api, config, clusters, kustomizations, git/helm repos and buckets.

Create user interface to enable GitOps on an existing cluster already connected to the Kubernetes extension.

From the initial functional spec. by @murillodigital:

The platform operator should be able to enable GitOps in an existing cluster already connected to the Kubernetes extension by clicking a button. A repo should be created and opened as a folder automatically to represent the objects being synchronized with the cluster. The platform operator will be able to see at a glance when the cluster has reached a reconciled state.

As a user, I want to select a non-AKS Kubernetes cluster that does not have Flux installed and have the various Flux components automatically installed in it.

Present the user with a right-click option to "Enable GitOps", only available when the cluster does not have Flux installed (see #36).

The command to execute against the cluster is flux install and should generate output similar to the following:

flux install
✚ generating manifests
✔ manifests build completed
► installing components in flux-system namespace
◎ verifying installation
✔ source-controller: deployment ready
✔ kustomize-controller: deployment ready
✔ helm-controller: deployment ready
✔ notification-controller: deployment ready
✔ install finished

One the install is completed, the cluster should reload and, as per #36, display the version of flux and all its related components.

use this for example: https://github.com/RandomFractals/vscode-snippets-viewer#dev-build

see full gitops sidebar mockup in #10 (comment)

Initial requirements from @murillodigital:

Deployments will show a list of all Kustomizations and HelmReleases visible to the user.

• Should display "at a glance" information similar to sources.

@murillodigital I will need this to get started on #17 per our prior discussion during this MVP project kickoff.

Please provide links to Kubernetes enabled sample app repos you might already have in place and you'd like to use for validating functionality of this GitOps vscode extension.

Also, I assume we'll be testing them in Azure cloud. I have an Azure account, but I'd rather deploy those sample apps under your org, so you cover the cost of spinning up those app nodes.

see #2 and docs: https://github.com/Azure/vscode-kubernetes-tools/tree/master/docs/extending

for running wego and flux commands

see managing terminals in vscode: https://code.visualstudio.com/docs/editor/integrated-terminal#_managing-terminals

terminal extension sample: https://github.com/microsoft/vscode-extension-samples/tree/main/terminal-sample

and this older pseudo terminal sample: https://github.com/microsoft/vscode-extension-samples/tree/main/extension-terminal-sample

As a user, I want to request an immediate reconciliation of any one of my Application.

Each Application is configured with a specific interval, users however are able to request instant reconciliation manually.

Allow the user to request immediate reconciliation of any application (HelmRelease or Kustomization), by right clicking (if other type of action is suggested given VS Code Extension best practices please commend for discussion) any on top level node of the sources panel and selecting an appropriate action.

The execution of reconciliation will require the flux cli.

In general, the command to execute is:

Commands

• HelmRelease Specific reconciliation example: flux reconcile helmrelease sample-helm-release -n default
• Kustomization specific reconciliation example: flux reconcile kustomization sample-kustomization -n default

Note: Make sure to pass the proper namespace and object name for each command given the element selected in the UI by the user.

Command Output

The output of the command may vary slightly between sources, but in general will be as follows:

• Sample HelmRelease Output:

flux reconcile helmrelease podinfo-helm -n default
► annotating HelmRelease podinfo-helm in default namespace
✔ HelmRelease annotated
◎ waiting for HelmRelease reconciliation
✔ HelmRelease reconciliation completed
✔ applied revision 6.0.0

• Sample Kustomization Output:

flux reconcile kustomization kustomization1 -n default
► annotating Kustomization kustomization1 in default namespace
✔ Kustomization annotated
◎ waiting for Kustomization reconciliation
✔ Kustomization reconciliation completed
✔ applied revision main/593cf7b48bf30079cda3c9c19c82f1c823ca0826

For any more specifics on command execution and outputs please refer to the official documentation:
See https://fluxcd.io/docs/cmd/flux_reconcile_helmrelease/ and https://fluxcd.io/docs/cmd/flux_reconcile_kustomization/ for reference.

see: https://github.com/weaveworks/vscode-gitops-tools/blob/main/.editorconfig and a5167fd

@usernamehw let's talk about linters, code editor configs, and coding style changes before making them next time.

I usually try to follow established code styles on a project, unless there is a consensus on making those changes and reformatting existing project code.

As a user, I want to request an immediate reconciliation of any one of my sources.

Each source is configured with a specific interval, users however are able to request instant reconciliation manually.

Allow the user to request immediate reconciliation of any source, by right clicking (if other type of action is suggested given VS Code Extension best practices please commend for discussion) any on top level node of the sources panel and selecting an appropriate action.

The execution of reconciliation will require the flux cli.

In general, the command to execute is:

Commands

The general command syntax is the following, which applies to all kids of Sources:

flux reconcile source <type of source> <name of resource> -n {namespace}

• Git Specific reconciliation example: flux reconcile source git sample-k8s -n default
• Helm specific reconciliation example: flux reconcile source helm sample-helm -n default
• Bucket specific reconciliation example: flux reconcile source bucket sample-bucket -n default

Note: Make sure to pass the proper namespace and object name for each command given the element selected in the UI by the user.

Command Output

The output of the command may vary slightly between sources, but in general will be as follows:

• Sample GitRepository Output:

flux reconcile source git sample-k8s -n default
► annotating GitRepository sample-k8s in default namespace
✔ GitRepository annotated
◎ waiting for GitRepository reconciliation
✔ GitRepository reconciliation completed
✔ fetched revision main/593cf7b48bf30079cda3c9c19c82f1c823ca0826

• Sample HelmRepository Output:

flux reconcile source helm podinfo -n default
► annotating HelmRepository podinfo in default namespace
✔ HelmRepository annotated
◎ waiting for HelmRepository reconciliation
✔ HelmRepository reconciliation completed
✔ fetched revision 8411f23d07d3701f0e96e7d9e503b7936d7e1d56

Note: A Failed reconciliation will produce output similar to the following:

flux reconcile source bucket podinfo-bucket -n default
► annotating Bucket podinfo-bucket in default namespace
✔ Bucket annotated
◎ waiting for Bucket reconciliation
✔ Bucket reconciliation completed
✗ Bucket reconciliation failed

For any more specifics on command execution and outputs please refer to the official documentation:
See https://fluxcd.io/docs/cmd/flux_reconcile_source/ for reference.

see #3 and add custom docs view with links to topics on GitOps: https://docs.gitops.weave.works

and https://fluxcd.io/docs/ for Flux

see #2, #12, and https://github.com/Azure/vscode-kubernetes-tools#dependencies

• updated changelog, screenshots, and docs with features delivered in Sprint 3
• create vscode-gitops-tools-v0.3.0.vsix installation package
• create v0.3.0 release tag

• use gitops.* and gitops.views.* for commands and views identifiers
• rename weave-logo.png icon to gitops-logo.png to replace later (#7)

with a link to flux CLI installation instructions: https://fluxcd.io/docs/installation/

As part of GitOps terminal initialization in #8, we should:

• list flux version installed
• display this prompt when flux check --pre command returns command not found error

with a link to wego CLI installation instructions: https://docs.gitops.weave.works/docs/installation

As part of GitOps terminal initialization in #8, we should:

• list wego version installed
• display this prompt when wego version command returns command not found error

As a user, I want to know what revision is currently fetched for any one of my sources.

There are three types of sources: HelmRepositories, GitRepositories and Buckets. Each of these sources will have fetched a specific version (aka. revision) of the source's content. This will always be shown in the form of a SHA (see status.artifact.revision in the HelmRepository sample below). Display the first 7 characters of the revision together with the source, following VS Code Extension best practices - only requests are, should be constantly visible (avoid mouseover tips) but I have no issue with it being nested below the source's node for example.

kubectl get helmrepository podinfo -o yaml
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"source.toolkit.fluxcd.io/v1beta1","kind":"HelmRepository","metadata":{"annotations":{},"name":"podinfo","namespace":"default"},"spec":{"interval":"5m","url":"https://stefanprodan.github.io/podinfo"}}
  creationTimestamp: "2021-08-31T16:47:30Z"
  finalizers:
  - finalizers.fluxcd.io
  generation: 2
  name: podinfo
  namespace: default
  resourceVersion: "1257490"
  uid: 258576df-4bfd-4dbb-9684-2928b06066bd
spec:
  interval: 5m0s
  timeout: 1m0s
  url: https://stefanprodan.github.io/podinfo
status:
  artifact:
    checksum: 8411f23d07d3701f0e96e7d9e503b7936d7e1d56
    lastUpdateTime: "2021-08-31T16:47:30Z"
    path: helmrepository/default/podinfo/index-8411f23d07d3701f0e96e7d9e503b7936d7e1d56.yaml
    revision: 8411f23d07d3701f0e96e7d9e503b7936d7e1d56
    url: http://source-controller.flux-system.svc.cluster.local./helmrepository/default/podinfo/index-8411f23d07d3701f0e96e7d9e503b7936d7e1d56.yaml
  conditions:
  - lastTransitionTime: "2021-08-31T16:47:30Z"
    message: 'Fetched revision: 8411f23d07d3701f0e96e7d9e503b7936d7e1d56'
    reason: IndexationSucceed
    status: "True"
    type: Ready
  observedGeneration: 2
  url: http://source-controller.flux-system.svc.cluster.local./helmrepository/default/podinfo/index.yaml

The command to execute to get the data for a source as shown above is:

kubectl get <GitRepository or HelmRepository or Bucket> <source name> -o yaml -n {namespace}

and add it to the vscode activity bar: https://code.visualstudio.com/docs/getstarted/userinterface#_activity-bar

That part of our extension code base has grown and needs some consistent imports, docs, code spacing, and other general code refactor touches.

see vscode extensions publishing docs: https://code.visualstudio.com/api/working-with-extensions/publishing-extension

Provide info on installing GitOps extension from local VSIX file until we release first version for this MVP.

Currently return types from running kubectl are written by hand. They are incomplete and could be wrong (for example, being nullable).

This issue tracks exploration of using https://github.com/drwpow/openapi-typescript to generate TypeScript types from https://github.com/kubernetes/kubernetes/tree/master/api/openapi-spec

with nodes from cluster configs in #2 and wego cli

@murillodigital to detail what top level nodes to display there

Selecting any cluster should automatically update the other views (sources, etc) to display the applicable items for that cluster.

Just to clarify - VSCode tree view doesn't support event on focus change (when pressing ↑ ↓), but it does support event when clicking or pressing Enter)

• Active cluster is marked in tree view (has collapsible symbol)
• Clicking on the cluster switches the active context
• Switching the context updates other tree views

to show prerequisites in gitops terminal from #8

if kubectl is not detected during our custom gitops terminal initialization.

Kubectl is required to load kubernetes cluster configs and for flux and wego cli tools to function.

We can use install kubectl command from k8s tools extension to kick off that command line tool installation process.

Need to decide whish properties to show:

• Api version
• Kind
• Name
• Namespace
• Cluster
  • ???
• Git repository
  • ???
• Helm repository
  • ???
• Bucket
  • ???
• Kustomize
  • ???
• Helm release
  • ???
• Flux controllers inside the cluster tree view
  • ???

Use vscode extension generator to scaffold it: https://github.com/Microsoft/vscode-generator-code

As a user, I want to be able to add my currently open repository as a GitRepository and Kustomization

Since we have a dedicated ./kubernetes folder for our integration with k8s tools extension and kubectl, I think kubernetesTools.ts api could be more readable if we move the results and k8s object types interfaces to separate .ts files to clearly track the imports and usage of those types in our tree views and other places.

This is in reference to all the interfaces defined here: https://github.com/weaveworks/vscode-gitops-tools/blob/main/src/kubernetes/kubernetesTools.ts#L169

use: https://raw.githubusercontent.com/weaveworks/weave-gitops/main/LICENSE

for display of running GitOps flux command or current step progress.

This is in addition to displaying full trace of flux commands we will provide in flux terminal output in #48.

VSCode k8s tools extension: https://github.com/Azure/vscode-kubernetes-tools

Investigate if we can use some of the k8s tools code and commands to drill into cluster workloads, services, pods and nodes.

We can specify that gitops depends on k8s tools in our extension manifest to enable some of those integrations.

see full gitops sidebar mockup in #10 (comment)

Initial requirements from @murillodigital:

Sources will show a list of all GitRepository, HelmRepository and Bucket resources visible to the user.

• It should be visible at a glance whether the sources have succeeded in fetching or are in some form of failed state.
• It should be visible at a glance whether there is an ongoing fetch operation. (likely using standard check, X and spinner icons)

It should be visible at a glance (via some UI element) whether the cluster is enabled for GitOps or not

As a user, I want to be able to tell whether Flux is running in my cluster, its version and the version and health of the various components that make up Flux:

CLUSTERS
   name (endpoint)
   	  Flux v0.16.2 is running
   	  helm-controller (version, status)
   	  image-automation-controller (version, status)
   	  image-reflector-controller (version, status)
   	  kustomize-controller (version, status)
   	  notification-controller (version, status)
   	  source-controller (version, status)

The simplest way to get this information is by running flux check against the cluster. The output of the command will be as follows - note that the output of the command is not quite parse friendly (neither json nor yaml), it is also possible to query for this information using kubectl commands but it would require multiple commands to be executed to get a similar set of details, please advice if this is a better direction:

flux check
► checking prerequisites
✗ flux 0.16.2 <0.17.0 (new version is available, please upgrade)
✔ kubectl 1.22.1 >=1.18.0-0
✔ Kubernetes 1.21.3+k3s1 >=1.16.0-0
► checking controllers
✔ helm-controller: deployment ready
► fluxcd/helm-controller:v0.11.2
✔ image-automation-controller: deployment ready
► fluxcd/image-automation-controller:v0.14.1
✔ image-reflector-controller: deployment ready
► fluxcd/image-reflector-controller:v0.11.1
✔ kustomize-controller: deployment ready
► fluxcd/kustomize-controller:v0.14.0
✔ notification-controller: deployment ready
► fluxcd/notification-controller:v0.16.0
✔ source-controller: deployment ready
► fluxcd/source-controller:v0.15.4
✔ all checks passed

Following the VS Code Extension guidelines, use node icons to quickly provide a visual hint of whether things are good or not. Note that there is a scenario where there will be suggestions, such as in the sample above where it is recommended to upgrade Flux to a new version. Handling that type of suggestion is likely outside the scope of this ticket.

k8s tools already have some built-in: https://github.com/Azure/vscode-kubernetes-tools/tree/master/snippets

We can present them in a custom k8s snippets view similar to this generic snippets extension: https://github.com/RandomFractals/vscode-snippets-viewer

and add GitOps/Flux specific snippets in /snippets as needed.

Provide a list of GitOps commands available via standard vscode View -> Command Palette ... menu and a screenshot of commands added so far.

see icon field in package.json from #4 and view container setup in #3

see #1 and add the following fields to package.json:

• icon
• publisher
• license
• readme
• repository
• bugs
• homepage
• keywords
• categories
• galleryBanner
• refine displayName
• add better description
  ...