workflow for doing a site update

commit and push, or pull all branches to be included in update into master branch. 

1. run tests, including unit, unit fixture, and selenium tests. 
- for unit tests: `perl t/test_fixture.pl --noserver t/unit`
- for unit_fixture tests: `perl t/test_fixture.pl t/unit_fixture
- for selenium tests: 
  run selenium2 server in seperate terminal with `java -jar selenium-server-standalone-2.53.0.jar`. This jar file should be in the vagrant home directory
  then run `perl t/test_fixture.pl t/selenium2/`
  
  if any tests fail, they can be run individually and troubleshot to make any necessary fixes to the code on the master branch, or to update the test itself

2. make a release tag

use the make_release_tag script from sgn_devtools repository to make a new release tag. For example, running 
`../sgn-devtools/make_release_tag -M -c "dependencies: patch db/00061 and db/00062"` in cxgn/sgn repo returns:
tagged master as release sgn-186.0
-p not passed, skipping auto-push.  You may want to run: git push --tags

then run `git push --tags` to push to github.

3. Update test sites
for example, to update sweetpotatobase-test.sgn.cornell.edu:
login to site in browser (sweetpotatobase-test.sgn.cornell.edu), and navigate to /about/status/logins. Make sure there are no other users logged in
ssh [email protected]
cd cxgn
cd cxgn-corelibs
git pull (update corelibs)
cd ../sweetpotatobase
git pull (update site-specific repo)
cd ../sgn
git checkout master
git pull 
git checkout tags/sgn-186.0
if there are tag dependencies, take care of them now. for example, if db patch db/00061 is a dependency, do:
  cd db/00061
  mx-run RedefineTraitsView -H db4.sgn.cornell.edu -D sandbox_batatabase -u bellerbrock
or if a cpan module like Imager::QRCode.pm is a dependency, do:
sudo cpanm Imager::QRCode.pm
then,
sudo service sgn stop
sudo service sgn start    *sudo service sgn restart would also cover these two lines
If for some reason your having trouble stopping the server you can us `ps aux` to find any sgn server processes and manually kill them,
or,
if its still not working, check 
tail -f -n 100 /var/log/sgn/error.log
or
tail -f -n 100 /var/log/sgn/access.log
for more info
once site is restarted, vist homepage to verify that things seem to be working

4. Update production sites

once test site is updated and things look good, repeat same process for live sites. There are only a few differences.
for example, to update sweetpotatobase live site, the differences are that you will:
ssh [email protected]
and for any db patches, the host and db name will be different. -H db5.sgn.cornell.edu and -D cxgn_batatabase
in some cases, if the test site database needs updating anyway (~ 1 per month), it may make sense to run the patch only on the live site database, dump it, then load the dump as the new test site database

5. Optional
Add info about any large/important changes to the homepage under the news section.