Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: obs_lsst
-
Labels:None
-
Story Points:1
-
Epic Link:
-
Team:Data Release Production
-
Urgent?:No
Description
test_translator.LsstMetadataTranslatorTestCase testMethod=test_imsim_translator failed in the lsst_distrib clean build, probably since we're now less than 53 weeks from the purported observation date, so it's not far enough in the future to trigger the expected warning.
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Team | Architecture [ 10304 ] |
Stealing this because just pushing the date into the future seems easy and it's getting in the way of Jenkins-testing of other tickets. Anyone else is welcome to look into the mysteries of why this only sometimes happens on another ticket later (assuming this is as easy for me as it seems).
| Status | To Do [ 10001 ] | In Progress [ 3 ] |
Also asking for volunteer reviews on Slack; if anyone else gets to it before K-T, just mark Reviewed.
| Reviewers | Kian-Tat Lim [ ktl ] | |
| Status | In Progress [ 3 ] | In Review [ 10004 ] |
| Reporter | Kian-Tat Lim [ ktl ] | Ian Sullivan [ sullivan ] |
| Reporter | Ian Sullivan [ sullivan ] | Kian-Tat Lim [ ktl ] |
| Reviewers | Kian-Tat Lim [ ktl ] | Ian Sullivan [ sullivan ] |
This looks fine, and I'm happy that this will solve the immediate problem. I'm a little worried this might trip us up again in the future, when the ImSim data might instead be too far in the past. Could you instead catch this specific type of error with a try/except block, or would that defeat the test?
| Status | In Review [ 10004 ] | Reviewed [ 10101 ] |
| Resolution | Done [ 10000 ] | |
| Status | Reviewed [ 10101 ] | Done [ 10002 ] |
| Story Points | 1 |
I think I just hit this trying to build {{eups distrib install -t v21_0_0 lsst_distrib }}for the SolSysSciCol sprint.
Is there a workaround (I'd like to stick to the official release, as this will be used for the next ~year)?
You could try installing from binaries instead; I think that should bypass the tests.
Alternatives include waiting for the much-improved and almost-out-the-door v22 or requesting a v21_0_1 patch (which, due to various reasons, almost certainly cannot come out before v22 does).
| Comment |
[ You could try installing from binaries instead; I think that should bypass the tests.
Alternatives include waiting for the much-improved and almost-out-the-door v22 or requesting a v21_0_1 patch (which, due to various reasons, almost certainly cannot come out before v22 does). ] |
| Comment | [ You could try installing from binaries instead; I think that should bypass the tests. ] |
The machines involved are on Ubuntu, so newinstall demands a rebuild 
.
I'm trying again with w_latest (need this for later today, unfortunately).
Binaries work fine on Ubuntu (ever since we switched to conda compilers/stdlibs); I do it all the time. You just need to lie about your OS, by setting
EUPS_PKGROOT=https://eups.lsst.codes/stack/redhat/el7/conda-system/miniconda3-py38_4.9.2-0.6.0
Thanks Jim Bosch – while it comes too late this time around, I will use it next time I need it.
This seems like a bug, though – shouldn't the install script know this? If so, can someone (Kian-Tat Lim?) pass this issue on to the right person in the packaging team to be considered for a fix? I've spent about 6 hours waiting for numerous from-source builds to fail yesterday (until the last one succeeded).
I'm not sure why this only shows up in the clean build and not in the release or tarball executions.