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 relevant automated tests.

Update and Perform a Clean Build

Before you run any tests, 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. From a command prompt, navigate to <labkey-home>/server
3. Run the gradlew cleanBuild build task to delete existing build information.
4. 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.
5. Verify that any merged files have merged correctly.
6. Resolve any conflicts within files that have been modified both by you and by another developer.
7. Run the gradlew deployApp target to build the latest sources from scratch.

Run the Test Suite(s)

LabKey maintains automated tests that verify most areas of the product.

If you modify server code, you should run tests relevant to the feature area you modified before pushing those changes to other developers. For changes to core platform modules, you should run a test suite with broad coverage (e.g. DRT or BVT). For changes to other modules you should run tests specific to those modules. Many modules have a test suite specific to that module.

See: Run Automated Tests

Test Failures

If a test fails, you'll see error information output to the command prompt, including the nature of the error and a stacktrace indicating where the test failed. A screenshot and HTML dump of page state when the failure occurred will be written to the <labkey-home>/server/test/build/logs directory, which can be viewed to see the state of the browser at the time the test failed.

A helpful resource: Java Debugging Tips

Checking In Code Changes

Once you pass the tests 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, use the git status command. This command displays a list of the files that you have modified, which you can compare to the repository version. Use git commit and then git push to commit them and then push them to the repository. Be sure to provide a log message with your check-in so that other developers can easily ascertain what you have changed. See the Feature Branch Workflow topic for more information on how we use feature branches and then merge them to the target branch.

After you check in, TeamCity will build the complete sources and run the full BVT on all of the supported databases as an independent verification. 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.