maratb
Joined 12 years ago
Karma
22
Submissions
8
Member since
Nov 6
Recent submissions
Comment · 7 years ago
That's fair. Although there are pretty tight internal controls on what Google can do on your Cloud Shell, you have to put a certain level of trust into Google here. Getting your own GCE VM and using SSH-in-the-browser is arguably more secure. Last I checked an f1-micro VM would suffice and fits under the 'always free' GCE cap.
Comment · 7 years ago
What about using Google Cloud Shell (https://cloud.google.com/shell/docs/; free, open to anyone with a Google account) as a jump host to your servers? Or using GCE's ssh-in-the-browser feature (https://cloud.google.com/compute/docs/ssh-in-browser) to connect to your own GCE VM (not free, in this case) and using it as jumphost?
Both Cloud Shell and SSH-in-the-browser use an in-browser SSH client, so the connection is encrypted all the way and not MITMable.
p.s. full disclosure: I work at Google on the team that maintains both of the above.
Comment · 12 years ago
There's a bit more to it. It's not enough to point Code Spotter / Coverity to a pile of code, it needs to observe the actual build in order to know precisely what is built and how it is built. While for some projects you can extract that information from the build files (e.g., maven poms), there are cases where this will fail. (For example, when the build generates some of the source files.) The most reliable way to understand how a project is constructed is to observe an actual build.
This is particularly true for C/C++ and C#, which are not yet supported on Code Spotter, but will be in the future. This precise understanding of a project's composition is one of the many reasons Coverity false positive rate is relatively low.
Comment · 12 years ago
Only if it comes from a repo that's hosted somewhere (i.e., not behind a firewall). Code Spotter is not restricted to GitHub, git, or any other particular SCM. If the code can be built, it can be analyzed.
Comment · 12 years ago
Sonar used to be just about running other open source tools, such as FindBugs, PMD, and Checkstyle. (BTW, Code Spotter runs FindBugs alongside Coverity analysis to complement the results). Sonar later added its own rule engine (Squid). More recently, I've come across SSLR - SonarSource Language Recognizer - which looks like a library for building custom coding rules.
Still, Coverity analyzer (which is what's behind Code Spotter) does deep interprocedural analysis and finds very different kinds of issues. I think the best way to see the difference is to try it out on a sample project.
Comment · 12 years ago
You can run on a hosted continuous integration service, such as Travis CI. The documentation is a little thin right now, but we will add this to the docs soon.
Comment · 12 years ago
Why? It is a new product (though based on the existing technology), a new model (cloud-based vs traditional Coverity on-premise), it is in free and unlimited beta, and we are soliciting feedback. Seems like a reasonable "Show HN", no?