Adds some ui-dev docs (#267)

* Adds so ui-dev docs

* how to kubectl the test cluster

Author: foot

README.md

@@ -1,3 +1,6 @@
 # weave-gitops-enterprise
 
-👋
+Information
+
+- Dev guide in [docs/developing.md](./docs/developing.md)
+- User docs at https://docs.gitops.weave.works

docs/developing.md

@@ -22,11 +22,11 @@ When making code modifications see if you can write a test first!
 
 Sometimes its nice to demo / experiment with the service(s) you're changing locally.
 
-### The `capi-service`
+### The `clusters-service`
 
 _Note: the following instructions will use a new local database, you can probably reconcile the internal cluster database with the local one with some fancy fs mounting, tbd..._
 
-The `capi-service` requires the presence of a valid entitlement secret for it to work. Make sure an entitlement secret has been added to the cluster and that the `capi-service` has been configured to look for it using the correct namespace/name. By default, entitlement secrets are named `weave-gitops-enterprise-credentials` and are added to the `wego-system` namespace. If that's not the case, you will need to point the service to the right place by explicitly specifying the relevant environment variables (example below).
+The `clusters-service` requires the presence of a valid entitlement secret for it to work. Make sure an entitlement secret has been added to the cluster and that the `clusters-service` has been configured to look for it using the correct namespace/name. By default, entitlement secrets are named `weave-gitops-enterprise-credentials` and are added to the `wego-system` namespace. If that's not the case, you will need to point the service to the right place by explicitly specifying the relevant environment variables (example below).
 
 An existing entitlement secret that you can use can be found [here](../test/utils/scripts/entitlement-secret.yaml). Alternatively, you can generate your own entitlement secret by using the `wge-credentials` binary.
 
@@ -56,7 +56,7 @@ Run the server:
 export KUBECONFIG=test-server-kubeconfig
 
 # Run the server configured using lots of env vars
-DB_URI=/tmp/wge.db CAPI_CLUSTERS_NAMESPACE=default CAPI_TEMPLATES_NAMESPACE=default GIT_PROVIDER_TOKEN=$GITHUB_TOKEN GIT_PROVIDER_TYPE=github GIT_PROVIDER_HOSTNAME=github.com CAPI_TEMPLATES_REPOSITORY_URL=https://github.com/my-org/my-repo CAPI_TEMPLATES_REPOSITORY_BASE_BRANCH=main ENTITLEMENT_SECRET_NAMESPACE=wego-system ENTITLEMENT_SECRET_NAME=weave-gitops-enterprise-credentials go run cmd/capi-service/main.go
+DB_URI=/tmp/wge.db CAPI_CLUSTERS_NAMESPACE=default CAPI_TEMPLATES_NAMESPACE=default GIT_PROVIDER_TYPE=github GIT_PROVIDER_HOSTNAME=github.com CAPI_TEMPLATES_REPOSITORY_URL=https://github.com/my-org/my-repo CAPI_TEMPLATES_REPOSITORY_BASE_BRANCH=main ENTITLEMENT_SECRET_NAMESPACE=wego-system ENTITLEMENT_SECRET_NAME=weave-gitops-enterprise-credentials go run cmd/clusters-service/main.go
 ```
 
 You can query the local capi-server:
@@ -90,6 +90,46 @@ cd ui-cra
 GITOPS_HOST=http://localhost:8090 yarn start
 ```
 
+## Developing the UI
+
+We usually develop the UI against the test server and by default the UI dev server will use that.
+
+```bash
+cd ui-cra
+yarn
+yarn start
+```
+
+Open up http://localhost:3000. Changes to code will be hot-reloaded.
+
+### UI against a local clusters-service
+
+When you need to develop the UI against new features that haven't made to the test cluster yet you can run your own clusters-service locally and point the UI dev server at it with:
+
+```bash
+CAPI_SERVER_HOST=http://localhost:8000 yarn start
+```
+
+### Testing changes to an unreleased weave-gitops locally
+
+Maybe you need to add an extra export or tweak a style in a component in weave-gitops:
+
+```bash
+# build the weave-gitops ui-library
+cd weave-gitops
+git checkout cool-new-ui-feature
+make ui-lib
+
+# use it in wge
+cd weave-gitops-enterprise/ui-cra
+
+# optionally clean up node_modules a bit if changes don't seem to be coming through
+rm -rf node_modules/@weaveworks/weave-gitops/
+
+# install local copy of weave-gitops ui-lib
+yarn add ../../weave-gitops/dist
+```
+
 ## How to update the version of `weave-gitops`
 
 [`weave-gitops-enterprise`](https://github.com/weaveworks/weave-gitops-enterprise) depends on [`weave-gitops`](https://github.com/weaveworks/weave-gitops). When WG makes a new release we'll want to update the version WGE depends on. It goes a little something like this:
@@ -107,9 +147,32 @@ cd ui-cra && yarn add @weaveworks/weave-gitops@$WG_VERSION
 open "https://github.com/weaveworks/weave-gitops/tree/v${WG_VERSION}/manifests/crds"
 ```
 
-## How to update the demo cluster
+## The test cluster
+
+The test cluster currently lives at a static ip but will hopefully move behind a DNS address with auth _soon_.
+
+Hit up http://34.67.250.163:30080
+
+### `kubectl` access
+
+The private ssh key to the server lives in the `pesto test cluster ssh key` secret in 1Password.
+
+1. Grab it and save it to `~/.ssh/cluster-key`
+2. Copy `kubeconfig` using this ssh key
+   ```
+   scp -i ~/.ssh/cluster-key wks@$34.67.250.163:.kube/config demokubeconfig.txt
+   ```
+3. Port forward the api-server port (6443) in another tab
+   ```
+   ssh -i ~/.ssh/cluster-key wks@$34.67.250.163 -L 6443:localhost:6443
+   ```
+4. Use the `kubeconfig`:
+   ```
+   export KUBECONFIG=demokubeconfig.txt
+   kubectl get pods -A
+   ```
 
-The demo cluster currently lives at http://34.67.250.163:30080/ but will hopefully move behind a DNS address with auth _soon_.
+### How to update the test cluster
 
 1. Figure out the version of chart you want to deploy. If we've done a release recently you can change it to `0.0.8` or a major version like that. To deploy a unreleased version from `main` or a `branch` we need to figure out the git ref version: