We recommend that you do all file edits within your checkout of the Submitty GIT repository on your local / host machine. This is a shared directory between the host machine and the virtual machine, so you can use your favorite code/text editor on your local machine.

The different stages of the installation and build process copy files from the repository to the installation directories, substitute variables, compile libraries, and change permissions. Depending on the type of software change, you will need to do different levels of re-installation to test those changes. The instructions below apply to changes you have made within your local Submitty checkout (including pulling new code from GitHub or switching to another branch).

NOTE: Depending on the types of changes you have made, the complexity of the reinstallation will vary (and thus also the time necessary to complete the installation). This page is organized with the simplest and least expensive reinstallation steps at the top of the page, and the more complicated and expensive steps at the bottom of the page.

Please also see Installation Version Notes

Submitty Help - List of Shortcuts

Website and Bin Script Changes

Incremental Development Updates

When incrementally editing code in the site, bin, or sbin directories, you can enable the Submitty development code watcher to automatically detect and automatically update those files on your installation through the scripts described above. The code watcher is convenient for testing changes to the website appearance (e.g., simple edits to CSS or twig/html/php). Once the update finishes, you should be able to reload the website and see the update.

Clearing Your Browser Cache

Update ALL Submitty Software

If you have made changes to the autograding pipeline or other more significant changes to Submitty infrastructure, it may be necessary to re-compile source code, apply database changes, update third-party libraries, and restart daemon processes.

Similarly, if you are upgrading your current working branch with multiple pull requests from the main Submitty branch, or if you are reviewing and testing the pull request from another developer that may include more significant Submitty source code changes, it will likely be necessary to conduct a more complete update and reset re-set of all of the Submitty source code.

Note: The above commands will also apply any necessary system and database Migrations.

Autograding Development

In addition to the submitty_install command above, if you modify an autograding configuration, you’ll probably need to:

System Re-Configuration

If recent development changes include modifications to files affecting the system installation process (e.g., changes to CONFIGURE_SUBMITTY.py, install_system.sh, Vagrantfile), you will need to either re-provision or re-build your VM from scratch to test these changes.

Re-Creating All Sample Course Data

Complete System Re-Installation

Virtual Machine Recovery using Snapshots

In the event of a non-recoverable error while working on Submitty the last resort is to, perform a fresh vagrant up. However, this process can be time-consuming. To avoid such situations and save time, it is highly recommended to take a snapshot when you first set up your Vagrant environment by following the tutorial links provided below:

By taking a snapshot at this initial stage, you can later revert to this saved state if needed, ensuring a quick recovery. Once you have restored the snapshot, you can then proceed with the following steps:

  1. Launch the virtual machine using vagrant up.
  2. Access the virtual machine with vagrant ssh.
  3. Run submitty_install command to conduct a more complete update and reset of all of the Submitty source code.