Pre-pushq checklist: Difference between revisions
From Genecats
Jump to navigationJump to search
(Created page with "* check that makeDoc and track descriptions are committed * if the track requires new code: ** set the CGI target version of the redmine ticket, so QA will check the track agains...") |
No edit summary |
||
| Line 1: | Line 1: | ||
* | * makeDoc and track descriptions must be committed | ||
* if the track requires new code: | * if the track requires new CGI code: | ||
** set the CGI target version of the redmine ticket, so QA will check the track against the new code when it goes out | ** set the CGI target version of the redmine ticket, so QA will check the track against the new code when it goes out | ||
* look at a whole chromosome e.g. chr1, to check for pile ups. | * look at a whole chromosome e.g. chr1, to check for pile ups. | ||
* If this is a track that has been on the RR before: | * If this is a track that has been on the RR before: | ||
** Does it have a release tag? If not: the new trackDb settings have to work with the old track | ** Does it have a release tag? If not: the new trackDb settings have to work with the old track, e.g. any bed/bigBed fieldCount will break it. TrackDb is pushed constantly, you trackDb changes can go live at any time. | ||
** If the table schema behind the track change, then change the track name (add a version number, e.g. omim2) | ** If the table schema behind the track change, then change the track name (add a version number, e.g. omim2) | ||
** Is it used by more than one assembly, check the other assemblies. Unusual grp or parent settings may disable the track on other assemblies. | ** Is it used by more than one assembly, check the other assemblies. Unusual grp or parent settings may disable the track on other assemblies. | ||
Revision as of 05:55, 8 December 2014
- makeDoc and track descriptions must be committed
- if the track requires new CGI code:
- set the CGI target version of the redmine ticket, so QA will check the track against the new code when it goes out
- look at a whole chromosome e.g. chr1, to check for pile ups.
- If this is a track that has been on the RR before:
- Does it have a release tag? If not: the new trackDb settings have to work with the old track, e.g. any bed/bigBed fieldCount will break it. TrackDb is pushed constantly, you trackDb changes can go live at any time.
- If the table schema behind the track change, then change the track name (add a version number, e.g. omim2)
- Is it used by more than one assembly, check the other assemblies. Unusual grp or parent settings may disable the track on other assemblies.
