|
|
| (4 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| ==Overview==
| | This page is no longer maintained. |
| Data and program code go from hgwdev to hgwbeta to the RR. You modify something on hgwdev. But when and how does it land on the RR?
| |
| ==All Routes==
| |
| There are five different routes that a change can take to get to the RR:
| |
| | |
| # CGI code, related .ra, .js and .css files: through git and the build process, which can take from one day to three weeks
| |
| # trackDb: through git, from the master branch through pushes, all the time
| |
| # htdocs static html files: pushed from hgwbeta to the RR
| |
| # /gbdb: pushed from hgwdev to the RR (because hgwbeta and the RR share their /gbdb)
| |
| # mysql tables: pushed from hgwdev to hgwbeta and then from hgwbeta to the RR
| |
| | |
| The "[http://genomewiki.ucsc.edu/genecats/index.php/CGI_Build_Process build process]" is run by the build meister who compiles the git master branch and copies the result to hgwbeta and then to the RR one week later.
| |
| | |
| As trackDb is pushed constantly, parts that should not be active on the RR have to be marked with "release alpha".
| |
| New tracks should always be marked with "release alpha", QA will then change "alpha" to "beta" or "public" as the track is getting ready.
| |
| | |
| == Route combinations (unusual) ==
| |
| Our release system is very important when changes touch different of the above "routes".
| |
| | |
| Examples:
| |
| * cgi and htdocs: A change to a static html file that requires a CGI change:
| |
| # Commit the CGI change, wait until it goes through code review etc and is on the RR
| |
| # Do not commit the html page, as someone else may push it to the RR.
| |
| # change the html page, commit and request a push from hgwdev to the RR
| |
| * trackDb and gbdb: A change to a bigBed file that adds a field that is referenced from a trackDb statement (e.g. mouseOverField)
| |
| # duplicate the trackDb entry, the old one has "release public", the new one "release alpha"
| |
| # The release alpha version gets the new line with "mouseOverField"
| |
| # modify the bigBed file on hgwdev BUT GIVE IT A DIFFERENT NAME (as hgwbeta and the RR share /gbdb)
| |
| # request a push to hgwbeta and tell QA to update the release tag, first to beta, then to public, when it goes to the RR
| |
| * sql and cgi: a change to a cgi that requires an additional field in a mysql table
| |
| # change the CGI and code it in a way that it can detect if the old or new table format is used by...
| |
| ## looking for a trackDb statement that indicates the version
| |
| ## looking at the track/table name (e.g. wgEncodeTf and wgEncodeTfV2)
| |
| ## looking at the table schema (checking if the field is present)
| |
| # make sure that the new table has a different name than the old table. This makes everything easier.
| |
| # create the new table on hgwdev
| |
| # wait until the build process has copied your change to the RR, then request a push of the new table to beta and then the RR. If you need different trackDb statements for some reason, make sure you use release tags on these
| |
| * htdocs and css
| |
| # change the .css first, wait until it's through the build process and on the RR
| |
| # now change the html pages and request a push to the RR
| |
