Gbib release

Executive summary for the buildmeister

run this command: buildGbibAndZip

Buildmeister VM (the future public VM)

• the build account has a virtual machine (VMs) added called "browserbox". It is the "master" image of the Gbib and used by the buildmeister.
• aliases to start and stop his/her VM: boxStart and boxStop.
• browserbox listens at port 1234 for web requests and at 1235 for ssh.
• From hgwdev, the buildmeister can do "ssh box" to connect to the box (configured in .ssh/config). There is no password, because the buildmeister's ssh key was added to the box.

beta VM

• the qateam account has a VM called browserboxBeta. It is the beta testing VM and used by QA.
• qateam has aliases to start and stop their VM: boxBetaStart / boxBetaStop
• browserboxBeta listens at port 1236 for web requests and at 1237 for ssh.
• one needs to use an ssh tunnel into hgwdev to use the webserver on this VM
• For ssh access, from hgwdev, qateam can do "ssh boxBeta" to connect to the box (configured in .ssh/config). There is no password, because the qateam's ssh key was added to the box.

Development

see Gbib development. (Note that any gbib can be converted into a hgwdev-like machine for offline development, with gcc, emacs, etc on it and even access to /hive)

Alpha testing

Alpha binaries from hgwdev's /usr/local/apache/cgi-bin directory can be copied into any gbib with this command:

 updateBrowser hgwdev <yourhgwdevusername> alpha

A developer can also copy the binaries from their own sandbox, e.g. if user braney wants to test braney's binaries on his gbib

 updateBrowser hgwdev braney braney

If user max wants to test braney's binaries on his gbib

 updateBrowser hgwdev max braney

In both cases, you will need to type your hgwdev password three times (unless you've setup public ssh keys in your gbib).

Troubleshooting: If we suddenly updated a machine, you might have to update your known_hosts sudo rm /root/.ssh/known_hosts

Beta testing

QA has three options:

1. QA can download the new ZIP created by the buildmeister and test on their own laptops (recommended)
2. If QA still has an older gbib on their own laptop, the command "updateBrowser hgwdev <username> beta" can be used to pull in the beta CGIs that were compiled by the buildmeister
3. QA can tunnel into hgwdev and use the browserboxBeta virtual machine there. See below how to tunnel into hgwdev.

See GBiB Testing for details on the QA GBiB testing procedures.

Tunneling into hgwdev to use browserboxBeta

This is for beta testing, option 3 above: to use the browserboxBeta on hgwdev, one has to connect with http to it. BrowserboxBeta accepts only connections from hgwdev, not from outside. You cannot connect from your desktop machine directly. So ssh on your desktop has to be told to forward at least one port to hgwdev. To make this happen, add this to your file ~/.ssh/config (create it if necessary) on your own OSX or linux machine:

 Host hgwdevtunnel
 Hostname hgwdev.gi.ucsc.edu
 User <YOURHGWDEVUSER e.g. rhead>
 #using 4321 to avoid clashing with your locally running gbib
 LocalForward 127.0.0.1:4321 127.0.0.1:1236

You can then do a "ssh hgwdevtunnel" to get connected to hgwdev and have the port 4321 on your machine forwarded to the box through the ssh connection to port 1236 on the box. Port 1236 is a http port of the browserboxBeta VM, so you can then test the browserbox that runs on hgwdev by pointing your internet browser on your laptop/desktop to http://127.0.0.1:4321

You can test the browserbox that is running on your own laptop at the same time by going to http://127.0.0.1:1234

Release

At the end of the beta week, the gbibBeta.zip can be copied into the store.

All Gbibs will update themselves when they start, as hgdownload will have been updated since the build happened.

At the every update of hgdownload which happens over the weekends, all boxes with activated auto-updates should update themselves automatically, see Gbib_auto_updates.

Release config changes to GbIb

• change a file, like hg.conf, updateBrowser.sh, ~/.bashrc or anything else in your own GBIB and test it.
• if it's the updateBrowser.sh script, scp it to hgwdev:/usr/local/apache/htdocs/gbib/updateBrowser.sh. If it's any other file, scp it to the correct subdirectory under hgwdev:/usr/local/apache/htdocs/gbib/push. The push/ directory is rsynced into the box's root directory, so the path in there has to correspond to the path in the GBIB.
• do a updateBrowser.sh hgwdev <yourHgwdevUsername> alpha on your own GBIB and type your password three times to try an auto-update on your own GBIB from the CGIs and other files on hgwdev (the data will come from hgdownload. This is because we have no alpha version of hgdownload.)
• do not forget to also scp the file that you changed into the kent repo, e.g. for the update script, scp to hgwdev.gi.ucsc.edu:kent/src/browserbox/root/updateBrowser.sh (this will not affect the push, it's only so we can keep track of the changes with git commits and they get reviewed)
• if everything is still working, notify the gbib buildmeister of the change. Depending on what you changed, request a push of either hgwdev:/usr/local/apache/htdocs/gbib/push or hgwdev:/usr/local/apache/htdocs/gbib/updateBrowser.sh to hgdownload:admin/gbib/push or hgdownload:admin/gbib/updateBrowser.sh.
• timing of the push:
  • many changes don't depend on the CGI version or the data version, so you can push them at any time. Most GBIBs will pick them up on the next Sunday night.
  • depending on the change, the timing can be important, as all gbibs on auto-update mode will update themselves with new CGIs and the new data tables when Jorge's scripts update hgdownload which usually happens on Sunday night. Your changes to the push/ directory or the update script will get copied into the gbibs at this time. For for CGI-dependent changes, it's best to do the push to hgdownload after the release (of course) but before the next Sunday

Troubleshooting

If we upgrade a machine, like hgwdev, you'll need to update the known_hosts for your GBiB:

sudo rm /root/.ssh/known_hosts