I recently set up source{d} on my work computer (which incidentally is a Windows machine). The main reason being that i was going to use it to analyze our code base at work and maybe even incorporate it into our build pipeline, as an alternative to SonarQube. From my understanding, source{d} has two main uses, language agnostic code analysis and code as data. In order to query the data (ie. the code and versioning metadata) source{d} provides a sql interface. Apparently source{d} applies machine learning in the code analysis process, which is one of the selling points that makes it really interesting. The possibilites with this approach are almost endless thinking about it, including predicting bugs or other any other problems that cannot be forseen with static analysis.
When starting out I didn’t know much about the inner workings of source{d}, I’d basically only made sure it would run on Windows. Due to the limitations of platforms we’re forced to comply with at work our codebase is in C# (.Net Framework). However as I was experimenting and fiddling around I soon figured out that C# on .Net Framework wouldn’t be supported as far as code analysis. It says in the documentation that C# is supported and not whether or not that would only be limited to .NetCore (The command srcd parse drivers list also returns csharp as a supported language). The source{d} engine runs dockerized on a Linux environment and consequently requires a switch to Linux containers. So naturally, if C# code analysis is at all supported (which it says it is), it’s limited to .NetCore. In other words it would be of no use to me, or at least not in the way i planned it to. One other aspect of source{d} is the code as data concept, which ultimately exposes a sql interface to a code repository, like a richer version of git log.
Either way it’s still useful on Windows if your codebase is in Java or Python or any of the other supported languages, so I figured I would still share the main setup steps I went through.
To download the software, I had to register my email at their site in order to get a download link. Upon completing this step, I simply downloaded the Windows version, unzipped it and followed these steps from the README by opening a PowerShell window as Administrator:
# create a new directory (if needed or just stick it somewhere)
mkdir ‘C:\Program Files\srcd’
# move the executable to the directory created above
mv engine_windows_amd64\srcd.exe ‘C:\Program Files\srcd’
# add the above location to path environment variable
setx /M PATH ”$($env:path);C:\Program Files\srcd”
Apply changes by opening a new PowerShell window, and then if Docker is not currently running Linux containers, switch like so:
& $Env:ProgramFiles\Docker\Docker\DockerCli.exe -SwitchDaemon
Now we’re good to go. To start working, init a repository either locally
srcd init
Or by providing a path:
srcd init path
I did the latter, which on a Windows machine would be like this:
srcd init C:\path\to\my-project
If everything went well, you should get output containing something similar to:
…level=info msg=“starting daemon with working directory: C:\path\to\project..
If not some Docker on Windows related bug or general nuisance probably occurred. Shared drives are a prerequisite, for one thing (more on that later). The path to your project could be another issue, ie. the workdir must be accessible to the user running srcd. In other words a workdir such as C:\Projects is preferable to one located under C:\Users.
For the source{d} sql interface two clients are available, one web-based and a cli. I prefer staying in the command prompt, so I just run:
srcd sql
Again if everything went well, you should get the gitbase prompt appearing rather instantly. One problem I ran into was that I got the response
..Error response from daemon: invalid mount config for type “bind”: bind source path does not exist..
which indicates that Docker has a problem accessing shared files. If you’re running Docker for Windows though, the solution seems to be to just open the GUI, uncheck shared drives, apply changes and then check again and apply. This could be related to updating your Windows password since you last checked the shared drives, and therefore Docker cannot any longer access the shared drives, which is why this step has to be repeated whenever the password has been changed.
Either way, with the sql client running let’s go ahead and start querying the repo. The cli seems really buggy though, so I was forced to run the web client instead:
srcd web sql
This should pop open a browser window (apparently any MySQL compatible client will work). I modified the sample queries to return any .cake (make for C#) files in HEAD:
**SELECT f.repository_id, f.file_path,
LANGUAGE(f.file_path, f.blob_content) AS lang, f.blob_content,
UAST(f.blob_content, LANGUAGE(f.file_path, f.blob_content)) AS uast
FROM refs AS r
NATURAL JOIN commit_files
NATURAL JOIN files AS f
WHERE r.ref_name = ‘HEAD’
AND f.file_path REGEXP(‘..cake’)**
Clicking on Code will actually open a new window with the code. The interace is not totally intuitive though, and i didn’t really get it to work as far as parsing any C# source code files. The examples provided (like Java and Python) worked fine though.
I haven’t really gotten around to finding a clear use of source{d} as far as where to put it in a workflow, doubtless it has a ton of potential though. As you can imagine, having a sql interface to your git history is very powerful and there are obviously a ton of interesting ways to query your data that would be very hard to achieve just with git log. I will certainly get back to source{d} in future posts.