Add support to Remotes about codetour

[lostintangent]

OK awesome, thanks!

[abulka]

Confirmed also in WSL - you can record steps when editing a remote SSH project in WSL (Windows Subsystem for Linux) v1 under Windows 10 but the steps won't playback.
The extensions installs itself OK on the remote, and allows you to 'record' but nothing plays back when you hit the play button on the tour, or when you double click on any individual step of the tour.
Hopefully the merge fixes this in WSL too?

[lostintangent]

@alefragnani Can you confirm that CodeTour is still working for you when doing container-based development? Though in your case, you didn’t install the extension in the container right?

@abulka Seems like we might need a new bug to track this issue. To confirm: did you install CodeTour in the WSL context or locally?

[abulka]

I installed CodeTour in the WSL context only, and encountered the playback problem.

I then switched to another, local project, installed CodeTour locally, and it worked for that local project.

[alefragnani]

@lostintangent ,

It's not fully working 😢 . @abulka reported that it's not being able to playback, but in my case, I wasn't able to record (playback worked perfectly). And you are right, I didn't install in the container, I used the local installation.

Then, I tested with the other releases, and noted that it stopped working with release 0.0.8. I used the Install Another Version.. command in VS Code.

I wasn't able to check the sources/debug the extension yet, to identify exactly where is the issue (probably tomorrow I could take a look). The 0.0.8 changelog says:

• Added the ability to associate a tour with a specific Git tag and/or commit, in order to enable it to be resilient to code changes
• Updated the tour recorder so that tours are automatically saved upon creation, and on each step/change_

Hope this helps

[alefragnani]

@lostintangent ,

I could find the reason behind my scenario while trying to record tour. It’s cause by the new “Git tag/commit association” feature.

I’m not sure why, but when connected to remotes, it’s not being able to initialize the Git API (even being a Git repo). The code below returns null:

https://github.com/vsls-contrib/codetour/blob/d7cd6ad2822ebf9fe0cebf8c4ad55e4895c32754/src/git.ts#L32

No git api is available and when it calls promptForTourRef(), it fails silently, instead of simply returning undefined and continue the steps:

https://github.com/vsls-contrib/codetour/blob/d7cd6ad2822ebf9fe0cebf8c4ad55e4895c32754/src/commands.ts#L508

Simply adding a check for valid api instance worked, but this is not a valid solution, because the remote folder, in my case, is a Git repo:

Hope this helps

[lostintangent]

@alefragnani In your case, is CodeTour installed on the UI or workspace side? I'm wondering if the problem is that CodeTour is running on the UI side, whereas your code (and the git data) is running on the workspace side.

[alefragnani]

@lostintangent It’s installed on the UI.

I’m not sure the problem is related to where the extension is installed, but on how it detects vscode.git being installed. BTW, the vscode.git extension itself is correctly installed (on UI) and enabled.

[lostintangent]

Could you try installing CodeTour in the remote workspace? I'm curious if it would work in that context.

[alefragnani]

Sure I can!

When installed in the remote workspace (using devcontainer.json file) it worked.

I’m using Insiders release, btw.

[lostintangent]

Yeah I'm not sure if vscode.extensions.getExtension works when the requesting extension is on the UI side, and the requested extension is on the remote/workspace side. CodeTour works fine locally, and it seems to work when installed in the remote workspace. But it seems like it has challenges when installed as a UI extension, and you're editing a remote workspace.

I'll check to see what the recommendation is for this.

[alefragnani]

Hm, do you mean the built-in extensions, like vscode.git, are automatically installed on the remote? Maybe that’s why, when you look at extension’s viewlet, all built-in extensions are tagged as Extension is enabled on ‘container-name’, instead of This extension is enabled globally

[lostintangent]

I believe so yeah. That's why you can install CodeTour in the remote context, and it finds vscode.git, without you having had to install it.

[alefragnani]

It makes sense, but if that’s the case, the remote development support (extensionKind tag in package.json) is not working as expected.

It is defined as [“workspace”, “ui”] and workspace means the extension runs on the remote machine. At least this is what I understand reading the docs.

[lostintangent]

That setting specifies that the extension can run in either the UI or workspace side. And the ordering indicates which one "wins" if the extension is installed in both.

That said, based on what we're discussing, it actually seems like CodeTour might need to just set this to ["workspace"], since it expects to be able to leverage Git metadata from the workspace.

[alefragnani]

I think you are right.

Below in the same docs page you have a better explanation, which says [“workspace”, “ui”] just prefers workspace but does not have any hard requirements.

Now, the extension requires Git, so a hard requirement was found 😁.

[alefragnani]

I see one small issue about taking that direction. The extension now must be installed on every remote, no matter which kind of workspace you have (Git or not).

Some could argue that the extension itself doesn't have a hard requirement on Git, but to the Git API provided by VS Code. At least, in this case, it's exactly how it is happening. You just require another extension. You don't require a Git lib/package.