CI/CD for the project

[dbabokin]

The key for moving forward with open sourcing the project is to have reliable testing and automated release procedures. The nature of JS-based projects is that they need to be constantly updated with dependency updates and track the API breakage (including in the latest versions of VSCode itself). This is true for every project, but for JS-based projects that it infinitely more important.

I'm not familiar how the testing for VSCode plugins can be done in automated way, but I'm sure there are best known methods for that. We need to do research and adopt the BKMs.

So from the project governance point of view, it should be as simple as that:

• dependency update available => dependabot creates a PR
• CI is green => changes can be merged.
• OpenSSF score card is green, CI is green => we can push the release button.

Let's do a research of what the possible options are and what is sufficient for CI testing of the project, build the implementation plan and execute.

[pbrubaker]

I will look at how some of the other extensions do this.

[pbrubaker]

I thought I'd take a moment to share how the modules in this project work together and enumerate their dependencies so we know what we're dealing with. There are relatively few dependencies overall. The core module that the vscode language extension relies on now, and the Visual Studio extension will rely on is ./server/ispc_languageserver This is the LSP. It is C# and when built it's dependencies are fetched through nuget at build time. They include:

Newtonsoft.Json Version = "13.0.3"
OmniSharp.Extensions.JsonRpc Version = "0.19.7"
OmniSharp.Extensions.LanguageServer Version = "0.19.7"
Serilog Version = "3.0.1"
Serilog.Extensions.Logging Version = "7.0.0"
Serilog.Sinks.File Version = "5.0.0"

The server also relies on ./ispc.tree-sitter and ./tree-sitter. Currently ./tree-sitter is a submodule.

The ./client-vscode directory contains the VSCode extension. It contains some json files that the editor uses for plugin description, configuration and some other language features like snippets. The TypeScript that is included is in the ./client-vscode/src/ and ./client-vscode/test directories only reference runtime dependencies.

./client-vscode/package.json lists the following dependencies.

    "devDependencies": {
        "@types/node": "^18",
        "@types/vscode": "^1.37.0",
        "typescript": "^5.5.2"
    },
    "dependencies": {
        "vscode-languageclient": "^7.0.0-next.8",
        "vscode-languageserver-protocol": "^3.16.0-next.6"
    }

The two files in the ./client-vscode/test directory only reference vscode and the standard assert module from node. The test code is just minimal boilerplate at the moment and doesn't do anything.

Currently the only TypeScript that's really used is in ./client-vscode/src/extension.ts and all that does is create a pipe, load the language server, and connect the two. It's 88 lines of boiler plate example TypeScript. It's dependencies are all improted at runtime from vscode and vscode-languageclient/node

Given this breakdown of dependencies, which will we have to manage with dependabot?

[pbrubaker]

I should note that the extension can currently only be built on Windows.

[aneshlya]

I enabled dependabot updates, there are 4 PRs now :)

[aneshlya]

@pbrubaker, how language server uses tree sitter and why is it needed?

[dbabokin]

I enabled dependabot updates, there are 4 PRs now :)

So we need a way to test the updates. So we need either someone who knows how to build and test it manually to build and test these changes (I'm looking at you, @pbrubaker). Or we should bring up a CI job, which does this.

[pbrubaker]

So we need a way to test the updates. So we need either someone who knows how to build and test it manually to build and test these changes (I'm looking at you, @pbrubaker). Or we should bring up a CI job, which does this.

@dbabokin I agree, we need to do both. For now, I will test and I'll solicit help from others for testing before a release. I also agree, we need to get a CI system setup to make sure everything at least builds. Building the VSCode part of the extension is possible on all platforms currently, however building the server which is C# is currently only setup to build with Visual Studio.

We could change this over to CMake but when we start to work on ./client-visual-studio we will need to build with Visual Studio anyway.

I'm open to thoughts on this. I believe we will always need human QA though.

@pbrubaker, how language server uses tree sitter and why is it needed?

@aneshlya I thought that Tree Sitter was doing more when I was talking with @ethandav but in looking at the code it looks like it's just a proof of concept that enumerates definitions in the current document at the moment.

The goal with using Tree Sitter was to enable parsing of a file and all of it's includes into an AST to support enhanced editor functionality like "Go to definition" or "Go to declaration" as well as autocompletion. This will also allow us to parse the entire include hierarchy and add user defined structures and functions to the auto complete dictionary. Right now the extension will only autocomplete things that are declared in the standard library,

This requires additional development as we will need to automatically parse files like c_cpp_properties.json in the project root, or potentially have our own ispc_properties.json to define project extension settings like include directories, etc..