Opening the host's browser automatically after Dev Container startup

[hoechenberger]

Note: I had previously posted this question on StackOverflow, but not received any response.

I'm using the Dev Containers extension v0.362.0 to do my development work. I would like to automatically open a specific website in the host's web browser after the container has started up.

After the container has booted, I can manually open a terminal and run:

xdg-open http://...

or

code --openExternal http://...

As expected, the host's web browser will open the requested page. The xdg-open command works because the remote extension seems to be setting the BROWSER environment variable, which then forwards the request to VS Code itself.

So far, so good!

But I cannot achieve the same when using a postStartCommand or postAttachCommand in devcontainer.json, i.e.,

  "postStartCommand": {
    "open-website": "code --openExternal http://..."
  },

and

  "postAttachCommand": {
    "open-website": "code --openExternal http://..."
  },

do not work: nothing seems to happen.

I figured that when these commands are run, the BROWSER variable is not (yet?) set.

I'm wondering if I'm perhaps missing something essential here? Any suggestions would be greatly appreciated.

[chrmarti]

BROWSER depends on the VS Code connection and these commands are run separately.

[hoechenberger]

@chrmarti Thank you very much. Would there be any recommended way to run a command once the connection has been established?

To give some more background: I'm using the desktop-lite dev container feature to provide browser-based VNC access and would like to automatically open the respective web app once the container has started up.

[chrmarti]

I think you could add a task of type shell or process (https://code.visualstudio.com/docs/editor/tasks#_custom-tasks) and run it automatically using:

            "runOptions": {
                "runOn": "folderOpen"
            }

[hoechenberger]

That's sounds like a clever idea, I will try it out and report back, thanks @chrmarti

[hoechenberger]

@chrmarti I tried your proposal with tasks and it's working great in the container!

There is one problem though: For our project, not all developers will want to use a Dev Container. However, if I ship a tasks.json file with the "runOn": "folderOpen" option, if the Dev Container is not used, the task will fail (at worst) or annoy the developer (at best). Even if I add some check to the task to find out if we're running inside a Dev Container (e.g., by checking if a certain env var has been set) and abort the task if we're not running in the container, the Task window would still pop up and add a bit of an annoyance.

So I suppose what I really want is the possibility to define "Dev-Container-only" tasks that I can specify somewhere in devcontainer.json, so I wouldn't have to add a tasks.json to my repository…

Or a section devcontainer in tasks.json, to complement the existing linux, osx, and windows configuration options.

Do you have any thoughts on this?

Thank you very much, Richard

[chrmarti]

You could use the following in your tasks.json to avoid the terminal getting revealed:

            "presentation": {
                "reveal": "silent"
            }

[hoechenberger]

I know, but I do want the terminal to be revealed if the task is actually run, so the user can observe the progress since it's long-running task (may take several minutes on some machines)

[hoechenberger]

@chrmarti Also please do let me know if you believe this is getting too much off-topic here and the issue should be closed or addressed elsewhere. In any case, I very much appreciate your time and the proposals you've made so far.

[hoechenberger]

@chrmarti I figured that extensions can also contribute tasks, so I'll now explore if and how that might be a feasible approach for me (providing a custom extension that is only installed in the Dev Container). I will report back once I have results.

[platform-kit]

@hoechenberger I am also looking for a solution to this use-case. Did you ever find a reasonable approach? Right now I am contemplating just adding node scripts that detect an ENV variable that is only available inside the container.