-
Notifications
You must be signed in to change notification settings - Fork 4
Add command to open web dashboard #11
base: main
Are you sure you want to change the base?
Conversation
Ensure Brigade terminal exists Signed-off-by: Radu M <[email protected]>
4185c50
to
24bbf67
Compare
@@ -33,6 +33,14 @@ | |||
"namespace": { | |||
"type": "string", | |||
"description": "Namespace where Brigade is configured in your cluster" | |||
}, | |||
"port": { |
There was a problem hiding this comment.
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": { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
24bbf67
to
5df3072
Compare
}, | ||
"port": { | ||
"type": "integer", | ||
"description": "Local port for the web dashboard. Default 8081" |
There was a problem hiding this comment.
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.
There was a problem hiding this 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" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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": { |
There was a problem hiding this comment.
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": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarify "in browser"?
There was a problem hiding this comment.
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": { |
There was a problem hiding this comment.
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']; |
There was a problem hiding this comment.
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'; |
There was a problem hiding this comment.
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.
This PR adds a command to open the web dashboard, by calling
brig dashboard --port {config} --open-dashboard {config}
.