GBiB Testing

This page is mainly for the QA team. For a more general overview of the GBiB release process, see Gbib release.

Testing During Preview2 week

Starting on v418, QA will begin testing GBiB during the Preview2 week to catch any errors so they do not result in a build patch during the final build.

To pull in the current changes on hgwdev, run the following command on the GBiB terminal:

updateBrowser hgwdev $USERNAME alpha

Testing During the Final Build week

All QAers do normal CGI testing on hgwbeta (in IE on winqa).

Official GBiB Tester

1. Official GBiB tester downloads gbibbeta.zip.
2. Tests his/her CGIs & tickets on GBiB.
3. Keeps Virtual Box updated (to ensure continued compatibility).
4. Tests hgMirror by downloading a track and ensuring it works.
   1. You may be interested in Max's hgc clicks per track plot when picking popular tracks to Mirror
5. Test loading a local track/hub from /folders by sharing local files.
   1. To a location on your host machine wget an example assembly hub and then configure VirtualBox to share folders with this location on the host. See this page for more information on configuring VirtualBox to share folders.
      sudo wget -r --no-parent --reject "index.html*" -nH --cut-dirs=3 http://genome.ucsc.edu/goldenPath/help/examples/hubExamples/hubAssembly/plantAraTha1/
   2. Use your terminal to enter GBiB: ssh browser@localhost -p 1235
   3. cd /folders and make sure that your test hub is there. Also navigate to http://127.0.0.1:1234/folders and make sure the hub is there as well.
   4. Lastly, load the local assembly hub: http://127.0.0.1:1234/cgi-bin/hgGateway?hubUrl=http://127.0.0.1:1234/folders/sf_test/hub/hubExamples/hubAssembly/plantAraTha1/hub.txt. Note that in this example the shared folder is called "test", and thus sf_test is the path on the gbib. If you name your example differently be sure to change the url accordingly.
6. Check that GBiB operates fine, you can run this selenium script in python2.7 from a terminal when your GBiB is operational. The first run of the script might be slow as it takes a moment to put all the public hubs into memory.

• NOTE: In a Mac OSX, to fix free memory you may have to occasionally restart while holding "command-R" (repair), then click "repair disk" on your selected HD.

All Other QAers

All other QAers test everything that they tested on hgwbeta (CGIs & tickets) on the GBiB beta VM so they don't have to wait for the download (see tunneling into hgwdev for more info on accessing the GBiB beta VM).

1. GBiB testing can be in any web browser.
2. Additionally, the hgTracks tester will turn on GbibSlowNet and open hgTracks to just the defaults, click into hgGene (report anything unusually slow).

Build Patches

1. Buildmeister rebuilds, including recreating gbibbeta.zip.
2. QA/buildmeister decide what needs, if anything, to be retested.
3. Buildmeister spawns a new GBiB beta VM on hgwdev of GBiB release candidate.

Release Day

1. No GBiB testing needs to be done on release day (as long as all goes to plan!)
2. As part of the post-release wrap-up, buildmeister requests a push of gbibbeta.zip to genome-store, which gets renamed to gbib.zip.

Urgent GBiB updates

• If we discover something really urgent, such as a critical security update, we can add things into released GBiB using the "push directory" (only rsyncable: mirror/data/gbib/push), which updates updateBrowser.sh. We don't expect to use it, but we can if there is something really urgent.

Genome-store

1. QA will test the functionality of the store itself only if there are changes to the store. In which case, a ticket would be created to track the change and would be assigned to a QAer for testing.
2. Official GBiB tester should check the first few releases to make sure gbib.zip made it to store.
3. In the future, we plan to create script (based on Steve's 2bitcompare) that compares the md5sum of the gbib.zip at the store to the gbibbeta.zip on Thurs or Fri after release to make sure the new GBiB file made it to the store.

Other

1. Brian Lee created a Selenium script that checks little things (like he has with Genome-euro). We hope this will detect small changes to the CGIs not captured in redmine that are fine on the hgwdev, hgwbeta and the RR, but break in GBiB.
2. Changes to GBiB only (vs. changes to CCIs and GBiB) will be tracked in redmines, then official GBiB QAer will address issues.
3. We don't think it is necessary to test GBiB on various OS because they are all running in a VM. Also, VB seems to use the same versioning for each operating system, so we don't think we need to worry about different VB versions on different OSs either.
4. Sometimes you want to test an update on your GBiB, say a change was just checked-in on hgwdev, you can run "updateBrowser hgwdev brianlee alpha" and you'll be prompted for your password three times as GBiB syncs to hgwdev.

NOTE: As soon as you start the GBIB, it may try to update itself. This makes switching off the auto-updates tricky. You can turn off the auto-update procedure for GBiB from your host operating system, not from within the GBIB, so before turning on the GBIB, with the following command:

VBoxManage guestproperty set browserbox gbibAutoUpdateOff yes

This is easier than the complicated procedure of disconnecting your computer from the internet (WiFi + ethernet) before starting GBiB and then turning off the auto-updates with the gbibAutoUpdateOff.