|
|
| Line 1: |
Line 1: |
| == Why use a demo browser? ==
| | Page Moved: http://genomewiki.ucsc.edu/genecats/index.php/Demo_sandbox |
| Frequently it is desirable to demonstrate browser features that are not yet ready to be pushed into the git master branch and/or not ready to be introduced into the genome-test (hgwdev) browser. This is especially so for large or experimental features that QA may need to test drive before they are approved to be put into the three week CGI release cycle. Alternatively, you may wish to demonstrate a track organization as represented in trackDb, but you can't build this trackDb into alpha yet. Keeping these features static in your own sandbox is the simplest solution. However, that is not always practical as we all have many things to work on. To help you there are 9 demo sandboxes cleverly named as demo1 through demo9.
| |
| | |
| == Claiming a demo browser ==
| |
| The demo browsers are sandboxes like your own and the cgis live on hgwdev in the appropriate cgi-bin directory: <code>/usr/local/apache/cgi-bin-demo''N''/</code><br>
| |
| To claim one, you should first see that no one else has that demo directory by seeing who owns the CGIs in that directory and how old they are:
| |
| <PRE>
| |
| ll /usr/local/apache/cgi-bin-demo2/
| |
| -rwxrwxr-x 1 tdreszer protein 11954236 Sep 15 2010 hgTracks
| |
| ...
| |
| </PRE>
| |
| If the CGIs in a demo cgi-bin are more than a couple months old, then that demo browser can be considered fair game. If there is any doubt, ask the owner.
| |
| | |
| Here is a list of current claims, but it is no doubt out of date as you read this:
| |
| === Claimed sandbox table ===
| |
| {| border="1" style="border-collapse: collapse"
| |
| ! style="background:#D6F6D6" | what
| |
| ! style="background:#D6F6D6" | who
| |
| ! style="background:#D6F6D6" | when
| |
| ! style="background:#D6F6D6" | why
| |
| |-
| |
| | demo1 || Tim, Angie, Kate || 2014-05-14 || whispers of jshint
| |
| |-
| |
| | demo2 || max || 2013-11-03 || publication v2
| |
| |-
| |
| | demo3 (no htdocs) || -|| - || -available-
| |
| |-
| |
| | demo4 || chin || 2013-08-09 || Proptotype encodeDataWarehouse work
| |
| |-
| |
| | demo5 (no htdocs) || max || 2013-10-05 || Bing pubs tracks (please do not remove without asking me, it's in a grant proposal)
| |
| |-
| |
| | demo6 || Angie || 2014-03-06 || testing some new javascript
| |
| |-
| |
| | demo7 || - || - || -available-
| |
| |-
| |
| | demo8 || - || - || -available-
| |
| |-
| |
| | demo9 || - || - || -available-
| |
| |}
| |
| | |
| == What about htdocs? ==
| |
| Much of the time you will not need a separate htdocs sandbox for your demo. When you will need this is if you have changes to Javascript, static HTML docs, images or CSS style sheets that cannot be put into the genome-test browser yet. If you need this functionality, you must claim a demo machine that has a htdocs sandbox directory (e.g. <code>/usr/local/apache/htdocs-demo2</code>). As of 3/6/2014, all demo machines except demo3 and demo5 have their own htdocs-demo''N''. You can check for yourself using this command:
| |
| <pre>
| |
| ls -1d /usr/local/apache/htdocs-demo*
| |
| </pre>
| |
| | |
| == Building your demo CGIs ==
| |
| Just like the default make targets in any other sandbox, the demo dirs are built based upon the value of USER in the make environment.
| |
| | |
| === Method 1: add USER=demo''N'' to make commands ===
| |
| You can set the value of any variable in the make environment on the command line like this:
| |
| <pre>
| |
| cd ~/kent/src/hg
| |
| make cgi USER=demo2
| |
| </pre>
| |
| | |
| === Method 2: modify your shell variable $USER ===
| |
| If you find yourself forgetting to add USER=demo''N'' too often, you can set your shell environment's USER to "demo2" (or whatever demo you have claimed) and then make your CGIs with the same make command as usual. It's a good idea to do this in a shell/window that you will use only for demo building.
| |
| <pre>
| |
| export USER=demo2;echo $USER # bash syntax
| |
| setenv USER demo2 # tcsh syntax
| |
| cd ~/kent/src/hg/
| |
| make cgi
| |
| </pre>
| |
| | |
| === rsync errors for cgi-bin-demo''N''/hg*Data ===
| |
| When you rebuild all CGIs on demo''N'', you might be halted by rsync errors if cgi-bin-demo''N''/hgNearData and hgGeneData files are owned by the previous demo developer (rsync attempts to chgrp and fails). If you do, just rm them and re-run your make.
| |
| <pre>
| |
| rm -r /usr/local/apache/cgi-bin-demo2/hgGeneData /usr/local/apache/cgi-bin-demo2/hgNearData
| |
| </pre>
| |
| | |
| === htdocs ===
| |
| All sandboxes except demo3 and demo5 have their own htdocs:
| |
| <pre>
| |
| cd ~/kent/src/hg/htdocs
| |
| make USER=demo2
| |
| </pre>
| |
| | |
| ''Do you need to do a full make'' (make clean;make...)? It is a good idea, but you are running in the context of your current git branch. If your src/lib and src/hg/lib have already been made, then you only need to assure the CGIs and possibly htdocs get rebuilt. Especially when you are first claiming the demo sandbox, I recommend a full make.
| |
| | |
| == Building trackDb_demo''N'' ==
| |
| Just like with your own sandbox, there is a trackDb_demo# for each assembly which will probably be well out of date when you claim a demo sandbox. Chances are that you only need to demo a new feature on one assembly however, so you can just rebuild that assembly as the demo user:
| |
| <pre>
| |
| cd ~/kent/src/hg/makeDb/trackDb
| |
| make DBS=hg19 USER=demo2
| |
| </pre>
| |
| Nothing is preventing you from making all assembles as the demo user. ''It is your time!''
| |
| | |
| '''''Remember:''''' If you modified your USER environment variable (Method 2 above), when you are done building demo''N'', set USER back to yourself!
| |
| <pre>
| |
| export USER=$(whoami); echo $USER # bash syntax
| |
| setenv USER `whoami` # tcsh syntax
| |
| </pre>
| |
| | |
| == Viewing your demo ==
| |
| This is just another sandbox, so view it like you view your own:
| |
| [http://hgwdev-demo1.cse.ucsc.edu http://hgwdev-demo1.cse.ucsc.edu]
| |
| [http://hgwdev-demo2.cse.ucsc.edu http://hgwdev-demo2.cse.ucsc.edu]
| |
| [http://hgwdev-demo3.cse.ucsc.edu http://hgwdev-demo3.cse.ucsc.edu]
| |
| [http://hgwdev-demo4.cse.ucsc.edu http://hgwdev-demo4.cse.ucsc.edu]
| |
| [http://hgwdev-demo5.cse.ucsc.edu http://hgwdev-demo5.cse.ucsc.edu]
| |
| [http://hgwdev-demo6.cse.ucsc.edu http://hgwdev-demo6.cse.ucsc.edu]
| |
| [http://hgwdev-demo7.cse.ucsc.edu http://hgwdev-demo7.cse.ucsc.edu]
| |
| [http://hgwdev-demo8.cse.ucsc.edu http://hgwdev-demo8.cse.ucsc.edu]
| |
| [http://hgwdev-demo9.cse.ucsc.edu http://hgwdev-demo9.cse.ucsc.edu]
| |
| | |
| '''''Remember:''''' Make sure to have your own copy of hg.conf in the /usr/local/apache/cgi-bin-demoN directory.
| |
| | |
| == Your demo responsibility ==
| |
| * Since you are reading this document, go ahead and update the table above, when you claim a demo sandbox.
| |
| * You are responsible for advertising the features you have made available in a demo browser.
| |
| * It is your responsibility to make sure all the CGIs necessary are working. If the feature you added is in the "hgc" CGI but you didn't bring "hgTracks" up to date, then don't be surprised if someone in your target audience thinks your new feature has created a mess and broken the browser in ways entirely unrelated to what you actually coded.
| |
| * Likewise, it is your responsibility to see that all the assemblies necessary are working. If QA wants to test your feature on a mouse assembly then don't cause them irritation by leaving the mouse trackDb_demo''N'' in some year old state.
| |
| * Finally, you can get out of the way when you are done with a demo browser. Perhaps you should just delete out the CGIs which will make it obvious that you are done with it. And if you are really responsible, you will update the claimed sandbox table above.
| |
| | |
| == Problems? Additions? ==
| |
| If these instructions are lacking or if you find and resolve problems with this documentation, '''''please extend or correct it'''''.
| |
