# Installation¶

There are two recommended options for installing CodeScene:

• Standalone Jar: see the section Run the Standalone CodeScene Application below.
• CodeScene inside a Docker container: We have an example on a docker file here, including an example on how to configure SSL.

We also support running CodeScene in Tomcat but it’s better to choose the other installation options if possible.

## Install the Supporting Tools¶

You need the following prerequisites to run CodeScene:

• A Java run-time (or JDK if you run from the command prompt), 64-bit version, at least Java 1.8 u162. You ensure you have the right Java version by typing java -version in a command prompt.
• Have a Git client on your path since the tool will assume there’s an executable named git somewhere. Your Git client has to be at least version 2.14. You ensure you have the right Git client version by typing git --version in a command prompt.

Please note that you can specify a custom Git client in the Configuration section once you login to CodeScene.

See also Configure your Environment for Git SSH key instructions.

## Run the Standalone CodeScene Application¶

The easiest way to get CodeScene up and running is by launching the standalone JAR:

java -jar codescene.standalone.jar


This will launch a web application that listens on port 3003 (you can override that by setting a different port through the environment variable CACS_RING_PORT.

Once you’ve launched the codescene.standalone.jar you just point your web browser to localhost:3003 to access CodeScene.

### Define the Root Paths for Persistent Data¶

CodeScene creates a local database for the analysis configurations. By default the database file resources/caacs_enterprise.db.mv.db is created in the working folder (that is, the directory where you run CodeScene).

You can override the default and provide a custom path through the environment variable CODESCENE_DB_PATH. Note that you need to specify a complete file name. As an example, if you specify /User/Services/CodeScene/configuration, CodeScene will create a persistent database file named /User/Services/CodeScene/configuration.mv.db.

CodeScene will also need access to a writeable file system where it can store analysis results and cloned Git remotes. In some environments (e.g. Docker) you might want to constrain those paths so that users don’t specify paths to a non-persistent storage. You do this by two optional environment variables:

1. CODESCENE_ANALYSIS_RESULTS_ROOT : Specifies the root path to where all analysis results will be written. CodeScene auto-generates a folder for each analysis project.
2. CODESCENE_CLONED_REPOSITORIES_ROOT : Specifies the root path to where Git remotes will be cloned locally. CodeScene auto-generates a folder for each analysis project.

The advantage of specifying these two optional environment variables is that the user won’t have to deal with configuring the result paths – it’s automated – and analysis results are always stored to a known partition.

### Configure the available Memory¶

RAM is a critical resource for CodeScene. In most cases 4G of RAM is more than enough, but if your codebase has large files (we mean really large, like +30,000 lines of code) you may need more memory to run the X-Ray analyses.

Note that Java’s virtual machine has a system dependent maximum that is typically lower than the total RAM available. That means you need to specify a higher threshold yourself when starting CodeScene. You do that by providing the -Xmx flag to java.

Here’s an example that shows how to allocate 10 gigabyte of RAM for CodeScene:

java -Xmx10G -jar codescene.standalone.jar


Note that the order of the arguments matter in this case.

### Avoid missing stack traces¶

In some situations, the JVM skips stack trace generation and you won’t get full stack strace details which may make troubleshooting more difficult. You’ll find a message indicating this happened in the logs, e.g.:

java.lang.ClassCastException
Stack trace of root exception is empty; this is likely due to a JVM optimization that can be disabled with -XX:-OmitStackTraceInFastThrow.


You can disable this optimization and make sure stack traces are always visible by using the -XX:-OmitStackTraceInFastThrow flag when starting the application:

java -XX:-OmitStackTraceInFastThrow -jar codescene.standalone.jar


### Optional: Run CodeScene in Kubernetes¶

Finally – and entirely optional – the CodeScene standalone JAR could also be run on Kubernetes. This might be an option if your organization already uses Kubernetes as a container management tool.

Follow the instructions here to setup CodeScene on Kubernetes.

### Optional: Specify a Path Prefix¶

In some network configurations, it may be necessary to access CodeScene with a path prefix, for example as internal.example.com/codescene. This might arise when CodeScene is one of several services running on the same server or it is not possible to attribute a dedicated subdomain for CodeScene. While a proxy server can be configured to correctly direct incoming requests, all the links in CodeScene, by default, are relative to the root path, /.

To avoid this, CodeScene can be run with the CODESCENE_PATH_PREFIX environment variable. The value supplied (which must be a valid path element, with no spaces or slashes) will be preprended to all internal CodeScene links.

(Note that this variable should not be used when running in Tomcat.)

## Run CodeScene in Tomcat¶

CodeScene is delivered as a WAR file (Web application ARchive). We recommend that you deploy it using Tomcat (https://tomcat.apache.org/index.html).

### Specify a file folder for the database¶

CodeScene uses an embedded database. That means, you don’t have to install any database or drivers yourself. However, you need to specify a path to a file folder where CodeScene is allowed to store its database. Here’s how you configure Tomcat to do that:

1. Open the file context.xml located under the conf directory in your Tomcat installation.
2. Add an <Environment> tag to context.xml that specifies the path to a folder you want to use for the database (see the example below).
3. Save context.xml.

Here’s an example on how context.xml may look on a Windows installation (note that you need to modify the path to fit your environment):

<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource> <Environment name="empear.dbpath" value="C:\\some\\path\\to\\the\\database\\empear.codescene" type="java.lang.String"/> </Context>  In case you run on a Linux-based system, you just specify a different path format. For example: <Context> <WatchedResource>WEB-INF/web.xml</WatchedResource> <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<Environment name="empear.dbpath"
type="java.lang.String"/>
</Context>


NOTE: Please ensure that Tomcat has write access to the folder you specify.

Optionally, you can specify a custom username and password to access the database. By default, CodeScene uses the ‘sa’ user with an empty password.

Add empear.dbuser and empear.dbpassword to the Context environment properties to customize DB username/password.

### Deploy the codescene.war¶

Once Tomcat is up and running, with your modified context.xml, you just copy the codescene.war to the webapps folder in your Tomcat installation.

### Access CodeScene¶

By default, Tomcat will launch CodeScene on port 8080 and at the path /codescene/. If you’re logged in on the server, you access the application on http://localhost:8080/codescene/login. You should see the activation screen in your web browser (see Fig. 1).

Enter the credentials you received in your license file. You’re now ready to login (see Fig. 2).

The first time you login, you use the same credentials to login as you used to activate the application. That is, give your CodeScene Username as User Name and your CodeScene License Key as Password.

You’re now up and running with CodeScene!

## Configure additional users¶

You are granted administration privileges each time you login with your license credentials (note that you can do that at any time, for example to administrate users).

You can add new users and assign them roles in the global configuration. Users and Roles describes this in greater detail.