Just leaving this here :-) ...

The static assets are compiled to []byte so they can be included in the binary, it's worth having a check in CI that what's committed matches what's generated.

Add support for larger datasets, especially around showing kustomized resources

We assume here the workload comes from a public repo, but I think in most cases it comes from a private repo. I would add flux create secret git <SSH secret> and flux create source git --secretRef=<SSH secret>.

Originally posted by @stefanprodan in #12 (comment)

@jpellizzari yes we need to keep the UI in-sync with flux2 release, in the same way we do for terraform provider. Some examples:

• https://github.com/fluxcd/flux2/blob/main/.github/workflows/update.yaml
• https://github.com/fluxcd/terraform-provider-flux/blob/main/.github/workflows/update.yaml

Originally posted by @stefanprodan in #41 (comment)

Make this look good:

Hi,

I'm not sure if this is something I've not followed correctly but following the README.md:

6. make dev to compile and run the app

> webui > make dev
reflex -r '.go' -s -- sh -c 'go run main.go'
[00] Starting service
[00] main.go:90:12: pattern dist/*: no matching files found
[00] (error exit: exit status 1)

After running:

7. npm start to start the frontend dev server (with hot-reloading)

this was fine but the process had already exited.

Is it acceptable to run npm start first and then make dev once Built in xx.xxs. is reported?

This may be user error, but if I navigate to and away from the sources tab I loose my context (top right) :

Originally posted by @bia in #19 (comment)

Should say instead "Add to HelmRelease" - this should work almost exactly like the existing workflow for other "workloads"

The behavior where unmanaged workloads have a call to action that allows you to add them to Flux as a Flux Kustomization, but do the same thing for unmanaged Helm Releases. All of the information about the release is already present in a configmap that helm install stores for each release in the history. It should work basically the same way.

The only thing you need the user to provide is the source repository URL, since helm doesn't apparently store that (and there is a possibility that it might not exist, you can do helm install from a chart that you have stored locally in your workstation. We won't be able to slurp those helm releases, but there probably won't be many users who have trouble understanding this.)

The release name, namespace, values can all be inferred by reading the values stored in the configmap (there is helm get values [releasename] which you can use to inspect them from the helm client).

(This idea came up during today's Flux/GOTK WW meeting)

It should also be noted that this graph starts to get untenable with large groups of reconciled objects. Here is the flux-system kustomization for example:

Originally posted by @jpellizzari in #46 (comment)

@jpellizzari can you please use https://github.com/fluxcd/flux2-kustomize-helm-example I think one important thing to show in such a graph are are all the kustomizations and helmreleases that originate from the main one, keep in mind that's common to have things like kustomization:flux-system -> k:infra + k:apps -> hr:infra + hr:apps -> kube:workloads and so on.

Originally posted by @stefanprodan in #15 (comment)

Using main@e17fc118e336accd370a326c388e5241efec6f69 and following the instructions in the README, I see this when I go to the Sources tab, while pointing at a newly-flux-bootstrapped cluster:

Error

There was an error fetching sources
Error: the json request could not be decoded

(it said the same thing when the cluster wasn't flux-bootstrapped).

Describe the bug
I see the following error, but not too sure if its a bug or if I am missing a configuration somewhere.

There was an error fetching namespaces
could not create client: kubernetes client initialization failed: no Auth Provider found for name "gcp"

To Reproduce
Steps to reproduce the behavior:

1. Download https://github.com/fluxcd/webui/releases/download/v0.1.0/flux-webui_0.1.0_darwin_amd64.tar.gz
2. Extract and run ./flux-webui
3. Navigate to http://localhost:9000
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

Desktop (please complete the following information):

• OS: [macOS Big Sur 11.2.3 (20D91)]
• Browser [chrome]
• Version [91.0.4472.101]

Describe the solution you'd like
I would like to be able to run flux webui using the the same frameworks I use to run flux. That is, using docker and helm charts.

Describe alternatives you've considered
Bundling the releases into a private docker image and create a helm chart from that.

When I run make dev in a pristine checkout, pkg/assets/assets.go is regenerated, and different. This is problematic because it means any change is going to be accompanied by a giant, impenetrable diff of assets.go.

Typically you would expect this to be avoided in the Makefile by pkg/assets/assets.go depending on the files that are included in it, so if they are not newer than assets.go, the generation is not run. It's possible Go 1.16's inbuilt filesystem utils would sidestep the problem.

Todo: add a CI check to ensure generated files are up to date

Originally posted by @jpellizzari in #34 (comment)

Hi there

I know this UI for Flux v2 is still experimental.
But are there any intentions in the near future to publish this application as a Docker image on DockerHub or something similar?
Currently I tried to build a Docker image on my own (https://github.com/adberger/fluxcd-webui) which seems to do the job but is probably kinda ugly.

Additionally I'm asking myself, if its possible to get the RBAC directly from the ServiceAccount token in a Pod instead of loading the kubeconfig-File (See in-cluster example)

Go 1.16 comes with support for embedded files golang/go#41191

• Re-use flux2 binary compiling steps
• Use go-releaser

Is your feature request related to a problem? Please describe.
I would like to have a quick view of what the web ui looks like. There are no screenshot on the GitHub README page, nor did I found one on the website. I have not searched a lot, but I expect those screenshots to be 'easily' accessible.

Describe the solution you'd like
I would like to have 1 or 2 screenshots of what the UI looks like on the GitHub page.
I would like to have the same screenshots (or even more if you see it appropriate) on the website.

Describe alternatives you've considered
Not other alternative.

Additional context
I am new to FluxCD. This is the 2nd time I look on this repo, and I am a bit furstated to not be able to see screeshots.

I'll admit I cargo-culted this from other makefiles to try and fix a CI error that turned out to be a mis-configured job. It can be removed.

Originally posted by @jpellizzari in #17 (comment)

I think it is worth distinguishing between the relationships "this object synced that object" as in a Kustomization->Deployment, and "this object is the owner of that object" as in Deployment->ReplicaSet. In terms of what we're trying to show the user, there's two different things going on: firstly, how syncs are configured, and secondly, what the outcome of a sync is. In the example, the first is represented by the sole kustomization object, but you can easily imagine a chain of "this kustomization synced that kustomization which synced this deployment ...."

Originally posted by @squaremo in #46 (comment)

Handle error states with a boundary to avoid weirdness with routing on error