Gbib development: Difference between revisions

From genomewiki
Jump to navigationJump to search
Line 18: Line 18:
You can start and stop browserbox-dev with the aliases devStart and devStop.
You can start and stop browserbox-dev with the aliases devStart and devStop.


== typical development cycle ==
== a typical development cycle to fix a gbib-only bug with the browserbox-dev ==


start browserbox-dev:
start browserbox-dev as qa:
   devStart
   devStart
   
   
connect + git pull + compile:
connect from hgwdev + git pull + compile with coredumps:
   ssh devbox
   ssh devbox
   compileCgis
   cd kent/src
  git pull
  make docs
  make cgi -j8 COREDUMP=1


You can now test the CGIs on port 1236 of hgwdev. You can also hack on the /home/browser/kent directory and e.g. run makes in there.
setup the tunnel on port 1236 to hgwdev from your laptop :
  ssh devtunnel


Typically, you will need to add hReplaceGbdb instead of cloneString at places where files in /gbdb are opened.
You can now test the CGIs on the devbox by going to the URL that fails in your browser e.g.:
  http://127.0.0.1:1236/cgi-bin/hgFileUi?db=hg19&g=wgEncodeAwgSegmentation
 
This should produce a new core file:
  ll /data/trash/core/core
  -rw------- 1 www-data www-data 73338880 Oct  3 08:07 /data/trash/core/core
 
Run gdb with the core file (the sudo password is "browser"):
  sudo gdb /usr/local/apache/cgi-bin/hgFileUi /data/trash/core/core
A typical solution is to replace cloneString with hReplaceGbdb at places where files in /gbdb are opened. Fix the bug and test after recompile.
 
Then don't forget to checkout the master branch and commit there (!):
  git checkout master
  git add hg/lib/fileUi.c
  git commit
  git push
 
Now you can file a build patch with this commit id.
 
== testing of alpha binaries on a real gbib ==


To do a more realistic test, the alpha binaries can also be put into the final browserbox.  
To do a more realistic test, the alpha binaries can also be put into the final browserbox.  


To copy the alpha binaries into the browserbox: Copy them from the devbox to alpha distribution rsync server directory (this command is defined in qateam's .bashrc) by running this command as qateam on hgwdev while the devbox is running (this will ssh into the devbox and rsync the binaries onto hgwdev):
To copy the alpha binaries into the browserbox: Copy them from the devbox to alpha distribution rsync server directory (this command is defined in qateam's .bashrc) by running this command as qateam on hgwdev while the devbox is running (this will ssh into the devbox and then copy the binaries onto hgwdev):
   boxUpdateAlpha
   boxUpdateAlpha


Now start the browserbox and pull the alpha binaries from the rsync server:
Now start the gbib running on hgwdev and pull the alpha binaries from the rsync server:
   boxStart
   boxStart # will show an error message if already running
   ssh box
   ssh box
   updateBrowser alpha
   updateBrowser alpha


You can now use the alpha CGIs on port 1234 of hgwdev or use ssh port forwarding to access them from localhost:1234.
Or you can run on the gbib on your own machine and type:
  updateBrowser


When you're done: stop the development box:
You can then test the alpha CGIs in the "real" gbib environment via 127.0.0.1:1234. Don't forget to start the ssh tunnel to hgwdev if you're using the gbib on hgwdev.
  devStop


== Pushing your changes to hgwdev ==
== Pushing your changes to hgwdev ==

Revision as of 15:41, 3 October 2014

This page is for developers, it's not relevant for QA. The QA page is Genome_Browser_in_a_box_config.

The devbox listens to http on 1236 and for ssh on 1237.

Box-specific development can happen on the devbox, a development version of the browserbox with git, gcc etc. For testing during development, a special command on the box can pull in the CGIs that were compiled on the devbox.

(sidenote: All virtual machines live in qateam/VirtualBox VMs/. The central virtualbox xml config file where they are registered is ~/.config/VirtualBox/VirtualBox.xml )

To start the devbox, you need to login as qateam onto hgwdev.

From hgwdev, you can then connect to the box with "ssh devbox". This works, because of the .ssh/config file:

 Host devbox
 Hostname localhost
 Port 1237
 User browser

You can start and stop browserbox-dev with the aliases devStart and devStop.

a typical development cycle to fix a gbib-only bug with the browserbox-dev

start browserbox-dev as qa:

 devStart

connect from hgwdev + git pull + compile with coredumps:

 ssh devbox
 cd kent/src
 git pull
 make docs
 make cgi -j8 COREDUMP=1

setup the tunnel on port 1236 to hgwdev from your laptop :

 ssh devtunnel

You can now test the CGIs on the devbox by going to the URL that fails in your browser e.g.:

 http://127.0.0.1:1236/cgi-bin/hgFileUi?db=hg19&g=wgEncodeAwgSegmentation

This should produce a new core file:

 ll /data/trash/core/core
 -rw------- 1 www-data www-data 73338880 Oct  3 08:07 /data/trash/core/core

Run gdb with the core file (the sudo password is "browser"):

 sudo gdb /usr/local/apache/cgi-bin/hgFileUi /data/trash/core/core

A typical solution is to replace cloneString with hReplaceGbdb at places where files in /gbdb are opened. Fix the bug and test after recompile.

Then don't forget to checkout the master branch and commit there (!):

 git checkout master
 git add hg/lib/fileUi.c
 git commit
 git push
 

Now you can file a build patch with this commit id.

testing of alpha binaries on a real gbib

To do a more realistic test, the alpha binaries can also be put into the final browserbox.

To copy the alpha binaries into the browserbox: Copy them from the devbox to alpha distribution rsync server directory (this command is defined in qateam's .bashrc) by running this command as qateam on hgwdev while the devbox is running (this will ssh into the devbox and then copy the binaries onto hgwdev):

 boxUpdateAlpha

Now start the gbib running on hgwdev and pull the alpha binaries from the rsync server:

 boxStart # will show an error message if already running
 ssh box
 updateBrowser alpha

Or you can run on the gbib on your own machine and type:

 updateBrowser

You can then test the alpha CGIs in the "real" gbib environment via 127.0.0.1:1234. Don't forget to start the ssh tunnel to hgwdev if you're using the gbib on hgwdev.

Pushing your changes to hgwdev

Direct - easier: set username for kent repo:

 cd kent
 git remote set-url origin ssh://YOURUSERNAME@hgwdev.cse.ucsc.edu/data/git/kent.git/
 git push
 # Don't forget to set it back to the public repo.
 git remote set-url origin git://genome-source.cse.ucsc.edu/kent.git


Indirect: simply rsync or scp to copy into your own homedir on hgwdev and commit there:

 rsync file USER@hgwdev:kent/PATH/FILE
 logout