If the LabKey Server team has provided you a Subversion account with read/write permission, you can check in changes that you make to the LabKey Server source. (Note that the public configuration described on the LabKey Server version control documentation page is a read-only account.) Before you check in any changes, you must make sure that your code builds, that it runs as expected, and that it passes the developer regression test (DRT).

Preparing to Run the DRT

Before you run the DRT, follow these steps to ensure that you are able to build with the latest sources:

1. Stop your development instance of Tomcat if it is running.
2. Run the ant clean build target to delete existing build informatino.
3. From your <labkey-home> directory (the root directory of your LabKey Server enlistment), use the svn update command to update your enlistment with the latest changes made by other developers.
4. Verify that any merged files have merged correctly.
5. Resolve any conflicts within files that have been modified both by you and by another developer.
6. Run the ant build target to build the latest sources from scratch.

Running the DRT

To run the DRT, follow these steps:

1. Start your development instance of Tomcat.
2. From a command prompt, navigate to <labkey-home>/test.
3. Run the ant drt target.
4. When prompted, enter the user name and password for an administrator account on your local development installation of LabKey Server.

The test targets you can call using Ant include:

• drt: Run the full test. The test is always compiled before it runs, so any changes to the test will be built before it runs.
• drt -Dtest="{name}[,{name}]": Run one or more individual tests. The name parameter is case-insensitive and can be the full name of any test class, or the name of the test class without the trailing "Test". For example, to run the MS2 test, you can pass any of the following to the command: "MS2Test", "MS2", "ms2test", or "ms2".
• drt -Dloop=true: Run the test in an infinite loop.
• drt -Dlabkey.port={portnumber}: Specify the port on which Tomcat is running, if it is running on a port other than the default port 8080.
• setPassword: Change your saved password.
• compile: Compile changes to the test code.
• usage: Display instructions for running the DRT test targets.

Test Failures

If the DRT fails, you'll see error information output to the command prompt, including the nature of the error, the point in the test where it occurred, the line of code on which it occurred, and the name of an HTML file, written to the <labkey-home>/test/build/logs directory, which shows the state of the test at the time that it failed. You can open this HTML file to glean clues about what action the test was trying to perform when it failed.

Modifying the DRT

You can add to or modify existing DRT tests and create new tests. To build your changes, use the ant compile target. You can also set up a run/debug configuration in IntelliJ to build and debug changes to the DRT.

To edit an existing DRT test, locate the test class beneath the <labkey-home>/test/src directory.

To create a new test, extend the BaseWebTest class, and add the name of your new class to the TestSet enum in TestSet.java.

Make sure that you test any changes you make to the DRT carefully before checking them in.

Checking In Code Changes

Once you pass the DRT successfully, you can check in your code. Make sure that you have updated your enlistment to include any recent changes checked in by other developers. To determine which files to check in, call the svn commit command. This command displays a list of the files that you have modified, which you can compare to the repository version. Be sure to provide a log message with your check-in so that other developers can easily ascertain what you have changed. An automated email describing your check-in is immediately sent to all who have access to the LabKey Server source project.

After you check in, our automated tools will also build the complete sources and run the full DRT as an independent verification, on all of the supported databases. You'll receive another email from the automated system letting you know whether the independent verification passed or failed. We request that you remain available by email from the time you check in until you receive the email confirming that the automated build and test suite has passed successfully, so that if there is a problem with your check-in, you can revert your change or check in a fix and minimize the amount of time that others are blocked.

If the automated test suite fails, all developers must halt check-ins until the problem is remedied and the test suite runs successfully. At that time the tree is once again open for check-ins.