Project: datamanagement
Issue DM-5135: Make ci_hsc buildable by Jenkins
1. Make sure {{ci_hsc}} is buildable by {{lsstsw}} / {{lsst_build}} (/) 2. Add {{ci_hsc}} to lsstsw/etc/repos.yaml so that one can request that Jenkins builds it. (/) 3. Verify that the test in {{ci_hsc}} fails on known broken tags and passes on known successful tags. (/) No dependencies will be added to {{lsst_sims}} or {{lsst_distib}}. This is meant to provide the ability to request that Jenkins do these builds and to fail if something has broken them. This will later be expanded to new packages {{ci_cfht}}, {{ci_decam}}, and {{ci_sim}}. The key goal is to make sure one hasn't broken obs_ packages in their butler interface or in their processCcd Additional Notes and Thoughts from HipChat Discussion [~ktl] Sounds good to me; we might have an "lsst_ci" top-level metapackage depending on all of them which is what Jenkins would run regularly. If the goal is to test obs_ packages, then my first instinct would be to put that in the obs_ package. Longer term goal to test the stack with different precursor datasets. If this is testing obs_ packages on a slower cadence than the built-in tests, it's OK for that to be a separate package. [~jbosch] Eventually, I think we need to run a CI dataset for each camera, then run some camera generic tests on each of those, then run some camera-specific tests on each of those.  So we don't want to go too far down a road in which all tests are camera-specific, but maybe we don't have a choice until we have some better unifying framework for them. I've certainly been putting some checks in {{ci_hsc}} that would be valid for all other cameras, if we had a CI package for them that went through to coadd processing.
Story points: 2