vscode devcontainer workflow

[michidk]

I already wrote an E-Mail to Alan, but never got a reply - but this here might be the better platform anyways:

I basically do all my development in vscode devcontainers. All of my globally-enabled vscode extensions work without any issues in any container without installing them there. Wakatime is an exception: It requires me to install the extension in every devcontainer manually.

Now there is a way to automatically install extensions in devcontainers (can be specified in the devcontainer.json). However, this file is synced to git and used by other developers as well. So I can't add a personal extension, such as wakatime, that only I use to that file.

It would be really great if wakatime would not be required to be installed in the devcontainer itself or if there is a way to do it automatically, just on my machine (without pushing that change to other devs).

[alanhamlett]

I already wrote an E-Mail to Alan, but never got a reply

Found your email, but will just reply here.

Wakatime is an exception: It requires me to install the extension in every devcontainer manually.

That's because WakaTime requires a binary on the machine, wakatime-cli, to communicate with the WakaTime API.

It would be really great if wakatime would not be required to be installed in the devcontainer itself

This might be possible, if we can get access to the file contents (located on the remote dev container) from the wakatime plugin (located on your machine). We also need to make sure the plugin can run subprocesses on your machine, because currently the plugin runs the subprocess on the dev container.

[tofupup]

It would be really great if wakatime would not be required to be installed in the devcontainer itself or if there is a way to do it automatically, just on my machine (without pushing that change to other devs).

Does adding

  "remote.containers.defaultExtensions": [
    "WakaTime.vscode-wakatime"
  ],

to your user settings not work? I use this for all personal productivity plugins that I don't want to force others to use and it seems to work OK for me!

[michidk]

I tested the approach @tofupup suggested for a while now. Looks like this works partly. First, it seems like the setting changed to:

  "dev.containers.defaultExtensions": [
    "WakaTime.vscode-wakatime",
  ],

Then it works, but the devcontainer has to be rebuilt and the Wakatime API key is entered every single time a container is rebuilt, which is quite annoying. This can be circumvented by adding this

		"source=${localEnv:HOME}/.wakatime.cfg,target=/home/vscode/.wakatime.cfg,type=bind,consistency=delegated"

to the devcontainer.json file. But then, everybody (even people not using WakaTime) would have this mount.

However, this could be easily fixed by reading the API key from the value of a setting instead of promoting the user to input the key.

[dcrouch79]

In case it isn't clear (it wasn't to me) the api key fix suggested by @michidk needs to be added to the mounts section of the devcontainer.json:

"mounts": [
    "source=${localEnv:HOME}/.wakatime.cfg,target=/home/vscode/.wakatime.cfg,type=bind,consistency=delegated"
],

Another catch, make sure the target home path /home/vscode/ is correct for your container setup. For me I had to change it to /home/dev/.

[IgnisDa]

@alanhamlett I think the following workflow for the extension will make sense:

• Check if first time running
• If yes, check if in devcontainer environment
• If yes, check if .wakatime.cfg exists in HOST system
• If yes, copy it to the required location
• If no, ask for the wakatime api key (i.e. follow the current behavior)

[danburonline]

I did it with the "wakatime.apiKey": "xyz" in the VS Code JSON setting. The WakaTime extension takes it inside the devcontainer (ergo it doesn't ask for it after creating a newly generated devcontainer), but it somehow fails and can't access the WakaTime API. Then, when inside a devcontainer and adding the API key via CMD + SHIFT + P and replacing it 1:1, it starts working (strange behaviour)...

Nonetheless, a dotfiles repo would solve this problem either way and I strongly recommend creating a custom dotfiles repo that can be automatically placed in a devcontainer when created.

[nemchik]

For my use case, adding wakatime.apiKey to my user settings.json works perfectly. I'm using vscode's settings sync with my GitHub account, and when I launch a GitHub CodeSpace it used to prompt every time a new codepsace was created for me to enter my WakaTime api key. Now that I've added that setting it no longer prompts.

[VagishVela]

@nemchik Is there a way to do that while pulling the value from an github secret?

[nemchik]

@nemchik Is there a way to do that while pulling the value from an github secret?

I believe so, yes.

According to https://code.visualstudio.com/docs/editor/variables-reference#_environment-variables it looks like you could create a secret named WAKATIME_APIKEY with your api key in the value and then in your settings.json you could set:

  "wakatime.apiKey": "${env:WAKATIME_APIKEY}",

[lohrm-stabl]

I have set "wakatime.apiKey": "MY KEY" in the settings. It still asks me every time to enter the key. However, the key is prefilled in the field now. But still rather unusable, if I have to accept this dialog every time I open a project.