search

Astroua / AstroCompute_Scripts

CASA timing scripts for high time resolution analysis of interferometric data sets
2 stars 4 forks source link

Unit tests #1

Open e-koch opened 9 years ago

e-koch commented 9 years ago

Once we have the basic workflow going, we need some tests of the code.

Two options

Once tests are in place, committing directly to this repo will be disabled and work will be done on our own forks. To make changes here, all changes will have to pass the tests.

e-koch commented 9 years ago

We'll also need testing data. Probably easiest to generate simulated data as part of the test suite.

radioastronomer commented 9 years ago

Hi All,

I'm not much used to GitHub workflows...

My suspicion is that the easiest thing to do would be to have a test-server no AWS and then commit changes from there when tests are passed.

Sincerely,

Greg

Gregory R. Sivakoff Assistant Professor of Physics University of Alberta, Edmonton, AB sivakoff@ualberta.ca

On 2015-09-28 10:24 AM, Eric Koch wrote:

Once we have the basic workflow going, we need some tests of the code.

Two options

  • have test suite that we run locally for any change.
  • use Travis or another CI service. The issue with that is the 1 Gb install for CASA and I'm not sure if they limit the storage. The Spectral-cube project has been avoiding this, and I think CARTA only needs casacore (@low-sky https://github.com/low-sky?) so it may not be worth it.

Once tests are in place, committing directly to this repo will be disabled and work will be done on our own forks. To make changes here, all changes will have to pass the tests.

— Reply to this email directly or view it on GitHub https://github.com/Astroua/AstroCompute_Scripts/issues/1.

e-koch commented 9 years ago

Travis will essentially do the same thing (and it's already automated). But if we need more flexibility, I agree that testing on AWS would be the way to go.

low-sky commented 9 years ago

The problem I see with Travis is that it spins its own VMs on a build trigger (like a commit). Since this project explicitly depends on CASA, naively this means pulling it over each time. This will probably fail on Travis and may piss off the people hosting the CASA images (NRAO). I think this might be a case where simple is better: build a test suite and run it manually before making major commits.

@astrilet suggests that you could build a docker image with CASA, host it on dockerhub, and cache the image on CircleCI. He likes this because there is a VM that will persist a little while. He also thinks it might work to cache CASA directly on CircleCI. TravisCI has a cache service but only for private repos.

e-koch commented 9 years ago

Ah, that sounds nicer. I have docker builds mostly ready so I'll check this out soon.