0871110b9e07cfb8001e6de9d156e7e7f74f8c25 max Fri Sep 4 17:00:53 2026 -0700 STRchive track now updates itself, and is on hg19 and hs1 as well as hg38 STRchive builds a Genome Browser bigBed with every release now and publishes it on their GitHub releases page, so there is nothing left for us to convert. A new otto job checks weekly for a new release, downloads the file into its own releases/ directory, sanity-checks the locus count, and repoints the /gbdb symlinks at it. Silent when there is no new release. See STRchive issue 333 for the correspondence that set this up. Their releases carry hg19, hg38 and T2T-chm13 (= hs1) files and we take all three, so the new strVar stanza lives in human/strVarNew.ra rather than under hg38. The bigDataUrls use $D, and hgTrackDb -strict drops any member whose file is missing, so each assembly gets only the tracks that were built for it: STRchive on all three, the other four on hg38 only. The description page is rewritten for the new evidence-level coloring, gains an evidence filter, and now says that the track updates itself and that older versions are on GitHub rather than here. All of that is alpha only. Nothing copies /gbdb/*/strVar/ out to the RR yet, so releasing this trackDb would have it promise data the RR does not have. The old hg38-only version stays as human/hg38/strVar.ra, tagged beta,public, until the sysadmins install the strchiveAutoPush cron drafted alongside the otto job. The header of strVarNew.ra lists what to delete and rename then. refs #38268 diff --git src/hg/utils/otto/strchive/strchiveAutoPush src/hg/utils/otto/strchive/strchiveAutoPush new file mode 100644 index 00000000000..f96c6d0ab40 --- /dev/null +++ src/hg/utils/otto/strchive/strchiveAutoPush @@ -0,0 +1,53 @@ +#!/bin/bash + +# Automatic push of STRchive GBDB files from hgwdev to hgwbeta, RR, +# genome-euro and genome-asia +# Requested by Max Haeussler, September 2026 + +# NOT INSTALLED YET. This is the draft to hand to the sysadmins: it belongs in +# /hive/groups/adminGit (branch hgwdev) as strchiveAutoPush, deployed to +# /root/strchiveAutoPush, with a line in hgwdev's /etc/crontab a little after the +# otto cron (otto.crontab runs strchiveOtto.py at 07:45 on Mondays): +# +# # weekly STRchive auto push (requested by Max Haeussler, Sept 2026) +# 15 8 * * 1 root /root/strchiveAutoPush +# +# Until this is in place the otto job keeps hgwdev current and the RR stays on +# whatever was last pushed by hand. +# +# rsync -avL follows symlinks, which matters here: /gbdb/hg38/strVar/strchive.bb +# is a symlink into /hive/data/outside/otto/strchive/releases// and the RR +# needs the file it points at, not the link. +# +# hs1 is served to the browser as a curated hub, but its /gbdb layout is the same +# as a native assembly, so it pushes exactly like hg19 and hg38. + +VICTIM="max@soe.ucsc.edu" +TODAY=`date "+%m%d%Y"` +OUTFILE="/hive/data/outside/otto/autoPushLogs/strchiveAutoPushLog/strchiveAutoPush.log.$TODAY" +PUSHTO="hgwbeta hgw0 hgw1 hgw2 genome-euro genome-asia" + +for i in $PUSHTO +do + for db in hg19 hg38 hs1 + do + echo "Pushing $db STRchive files to $i" >> $OUTFILE + if rsync -avL --rsh=ssh \ + /gbdb/$db/strVar/strchive.bb \ + /gbdb/$db/strVar/strchive.version.txt \ + $i:/gbdb/$db/strVar/ >> $OUTFILE + then + echo " Completed at `date`" >> $OUTFILE + echo " " >> $OUTFILE + else + echo " ERROR - strchiveAutoPush failed for $db to $i with code $?" + echo " ERROR - strchiveAutoPush failed for $db to $i with code $?" >> $OUTFILE + exit $? + fi + done +done + +# If we get here, everything completed without problems. Send mail to the +# official victim and we're done. + +cat $OUTFILE | mailx -s "strchiveAutoPush completed" $VICTIM