Skip to content
This repository has been archived by the owner on Jun 1, 2022. It is now read-only.

Add command to open web dashboard #11

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

radu-matei
Copy link
Contributor

This PR adds a command to open the web dashboard, by calling brig dashboard --port {config} --open-dashboard {config}.

Ensure Brigade terminal exists

Signed-off-by: Radu M <[email protected]>
@@ -33,6 +33,14 @@
"namespace": {
"type": "string",
"description": "Namespace where Brigade is configured in your cluster"
},
"port": {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I debated whether to add this as a picker, or as a config - and ultimately, I don't think this is something you want to configure every time.

"type": "integer",
"description": "Local port for the web dashboard. Default 8081"
},
"open-dashboard": {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a picker?
I feel about it the same way as for the port, but I can be persuaded otherwise.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you wanted to make it optional, you could have a notification: Dashboard is available on http://localhost:8081. with a button Open in Browser?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, the browser-opening functionality is baked into brig - so you would either have to do it before starting the tunnel, or reimplement the functionality.

By default it is enabled though.

},
"port": {
"type": "integer",
"description": "Local port for the web dashboard. Default 8081"
Copy link
Contributor Author

@radu-matei radu-matei Jun 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the default value actually used by VS Code if no configuration is provided?
The description of the default field says: A default value. Used by suggestions, which makes me think the value is not actually used.

@radu-matei radu-matei mentioned this pull request Jun 21, 2019
Copy link
Contributor

@itowlson itowlson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aaugh, sorry to nitpick another of your PRs, but I have some concerns about the naming and about the UI of the port-forwarding process...

},
"open-dashboard": {
"type": "boolean",
"description": "Open the dashboard in the browser. Default true"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would skip this. What does false mean anyway - forward the local port but don't open the browser?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is the same UX as brig dashboard.

},
"port": {
"type": "integer",
"description": "Local port for the web dashboard. Default 8081"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't really be the user's problem should it? Can't we use something like port-finder to pick an arbitrary open port?

{
"command": "brigade.openWebDashboard",
"category": "Brigade",
"title": "Open Web Dashboard"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need the word 'Web' here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming due to #12

const cmd = `${bin} dashboard ${args}`;

const terminal = ensureTerminal();
terminal.sendText(cmd);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We had this in the k8s extension and I have come to be less and less keen on it. For the API I ended up not doing port-forwarding in a terminal, because the purpose of the port forward API was to enable extensions to open their Web dashboards, and port forwarding was an implementation detail that shouldn't take over that much of the screen. Instead, I put an icon in the status bar to indicate that one or more ports were being forwarded. The user could click that icon to see what ports were being forwarded, and why, and to close ones that were no longer needed. I'd prefer to see us adopt something like that approach here, rather than the in-yer-face terminal. k8s implementation is at https://github.com/Azure/vscode-kubernetes-tools/blob/795246a8b9f29cdd7ac8d0d9004aad3eb5972a3f/src/api/implementation/kubectl/v1.ts#L21 though not directly portable!

An alternative approach would be to just keep the port open until the end of the editor session with no UI at all, but a Close Dashboard command for those who really really care about the port being kept open (or the brig process being kept alive).

@@ -17,3 +17,16 @@ export function toolPath(tool: string): string | undefined {
export function getConfiguredNamespace(): string | undefined {
return vscode.workspace.getConfiguration(EXTENSION_CONFIG_KEY)['namespace'];
}

export function getConfiguredPort(): number | undefined {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getDashboardPort()?

@@ -33,6 +33,14 @@
"namespace": {
"type": "string",
"description": "Namespace where Brigade is configured in your cluster"
},
"port": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the name, this could be any port. Can we make it clearer that it's the port to use when opening the dashboard?

"type": "integer",
"description": "Local port for the web dashboard. Default 8081"
},
"open-dashboard": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarify "in browser"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initially, I wanted to preserve the CLI flags in the config, which might have not been the ideal choice.

"type": "integer",
"description": "Local port for the web dashboard. Default 8081"
},
"open-dashboard": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you wanted to make it optional, you could have a notification: Dashboard is available on http://localhost:8081. with a button Open in Browser?

}

export function openDashboard(): boolean {
const cfg: boolean = vscode.workspace.getConfiguration(EXTENSION_CONFIG_KEY)['open-dashboard'];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This reads like "open the dashboard"; consider e.g. "shouldOpenDashboardInBrowser".

@@ -7,6 +7,7 @@ import { BrigadeResourceDocumentProvider } from './documents/brigaderesource.doc
import { hasResourceURI } from './projectexplorer/node.hasresourceuri';
import { onCommandRunProject } from './commands/runproject';
import { onCommandRerunBuild } from './commands/rerunbuild';
import { openWebDashboard } from './brigade/brigade';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather command handlers not go straight into the CLI wrapper. I know it works, but it feels like a mixing of abstraction levels. The brigade module's job is to surface the brig CLI to the extension UI; although in this case there may be nothing for the UI to do other than invoke the CLI (because the CLI provides all the UI!), it feels uncomfortable not to have a separate place for the command to land. Maybe I am being silly though.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants