Closed clouedoc closed 1 year ago
New infos: the entity
string should indicate that it is remote somehow.
Or the file filter should be skipped.
From the wakatime-cli repository:
func filterFileEntity(h heartbeat.Heartbeat, config Config) error {
if h.EntityType != heartbeat.FileType {
return nil
}
if h.IsUnsavedEntity {
return nil
}
if h.IsRemote() {
return nil
}
entity := h.Entity
if h.LocalFile != "" {
entity = h.LocalFile
}
// skip files that don't exist on disk
if _, err := os.Stat(entity); os.IsNotExist(err) {
return fmt.Errorf(fmt.Sprintf("skipping because of non-existing file %q", entity))
}
// IsRemote returns true when entity is a remote file.
func (h Heartbeat) IsRemote() bool {
if h.EntityType != FileType {
return false
}
if h.IsUnsavedEntity {
return false
}
return remoteAddressRegex.MatchString(h.Entity)
}
Link It should match the following regular expression:
// remoteAddressRegex is a pattern for (ssh|sftp)://user:pass@host:port.
var remoteAddressRegex = regexp.MustCompile(`(?i)^((ssh|sftp)://)+(?P<credentials>[^:@]+(:([^:@])+)?@)?[^:]+(:\d+)?`)
I think that something could be done here to add SSH remote information to the heartbeat.
It could pass information about the remote host.
There is already relevant sanitization happening inside wakatime-cli
:
func hideCredentials(h Heartbeat) Heartbeat {
if !h.IsRemote() {
return h
}
match := remoteAddressRegex.FindStringSubmatch(h.Entity)
paramsMap := make(map[string]string)
for i, name := range remoteAddressRegex.SubexpNames() {
if i > 0 && i <= len(match) {
paramsMap[name] = match[i]
}
}
if creds, ok := paramsMap["credentials"]; ok {
h.Entity = strings.ReplaceAll(h.Entity, creds, "")
}
return h
}
I'm unsure, but maybe relevant information can be extracted from uri
instead of fileName
: https://github.com/microsoft/vscode/blob/69c8a7594d5efbc391d873157184b0317991cd11/src/vs/workbench/api/common/extHostDocumentData.ts#L61-L63
Are you running the wakatime extension installed on the remote vscode container? In that case, it should be running your two wakatime-cli commands on different machines. The first one # When editing a file on my local computer (works)
would execute on your host machine, and the second one # When editing a file on an SSH remote (does not work)
would execute on your remote machine. That means relative to your remote machine, /home/clouedoc/Code/another-censored-project/.pre-commit-config.yaml
should exist. For ex: if you ssh into your remote machine and type ls -l /home/clouedoc/Code/another-censored-project/.pre-commit-config.yaml
you should see the file's info printed.
Hello @alanhamlett, thanks for checking in!
I am running the extension in UI mode as explained in the README.md: https://github.com/wakatime/vscode-wakatime#ssh-configuration. Additionally, I made sure to remove all wakatime-related files and uninstalling the WakaTime extension on the server side.
It's not a container but rather a shared SSH server used by my coworker and I. Running the wakatime-cli command on the server will cause one of us to have additional undeserved heartbeats, so I had to to disable Wakatime and thus loose a good share of my stats.
If I'm correct, running the extension in UI-only mode causes the command to be issued locally even though I am editing a remote file. This then causes the file existence checks to fail since it does not exist on my laptop, but rather on the server.
This might be fixable by providing wakatime-cli with this syntax when editing a remote file: (ssh|sftp)://user:pass@host:port:
/home/user/my-project/hello.md (instead of /home/user/my-project/hello.md
). This is because the heartbeat will be marked as remote, thus exiting the check function early and bypassing the file existence check.
As far as I've searched I didn't find anything that would suggest that this is a problem related to my configuration but rather a total lack of feature by the extension, even though it sorts-of claims that it does support running in UI-only mode in the latest README.md. Other people might be experiencing the same problem (#304 - not sure about what protocol could be used to describe the file in this case, though...)
If I'm correct, running the extension in UI-only mode causes the command to be issued locally even though I am editing a remote file.
Yes, correct.
I see the problem now, and we can get a new vscode-wakatime version released today to fix it for you. The Document.uri
property has scheme: "vscode-remote"
when running locally (ui
) and connected to a remote SSH server.
Fixed in v22.1.0 just released today.
@alanhamlett Thank you š
// TODO: how to support 'dev-container', 'attached-container', 'wsl', and 'codespaces' schemes?
To answer your question, here are some solutions I thought of:
filename.replace(/(dev-container|attached-container|wsl|codespaces):\/\//g, "ssh://")
--skip-file-existence-check
in wakatime-cliOf course, you know better than me, it's just some food for thoughts. I don't care, as I am now a satisfied user š
It might work already for wsl
without changes, and so far most people seem to be using dev-container
in a solo environment not shared so they're fine running the wakatime plugin in the remote container. Let's just wait and see if anyone reports an issue around WSL or Dev Containers.
Hi, I cannot send heartbeats when editing on an SSH remote.
I get this suspicous message in
.wakatime.log
:filter file: skipping because of non-existing file
I also get the following:no heartbeats left after filtering. abort heartbeat handling.
Here are log lines from a recent programming session on an SSH Remote:
Here is the CLI command that is called by the Wakatime VSCode extension: (seen in debug logs)