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
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.
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.