-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vscode devcontainer workflow #280
Comments
Found your email, but will just reply here.
That's because WakaTime requires a binary on the machine, wakatime-cli, to communicate with the WakaTime API.
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. |
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! |
I tested the approach @tofupup suggested for a while now. Looks like this works partly. "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. "source=${localEnv:HOME}/.wakatime.cfg,target=/home/vscode/.wakatime.cfg,type=bind,consistency=delegated" to the 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. |
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 |
@alanhamlett I think the following workflow for the extension will make sense:
|
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. |
For my use case, adding |
@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": "${env:WAKATIME_APIKEY}", |
I have set "wakatime.apiKey": "MY KEY" in the settings. |
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).
The text was updated successfully, but these errors were encountered: