Try setting up CI

[sampsyo]

A totally not ready, experimental approach to #53. Nothing to see here yet.

[sampsyo]

One note as this starts to take shape: so far, this only runs the tests for slow-odgi. It should eventually also run the tests for the data generator and the new tests for the parser added in #136.

[sampsyo]

I think this is ready to go (i.e., we can merge if @anshumanmohan & @susan-garry approve)! The point is to make sure our tests that are currently pass keep passing, and we don't accidentally break some tests without noticing (which has happened a few times!). It will also hopefully give us some confidence to do some refactoring, and even changing the test setup, because we'll get feedback if we do anything wrong.

This CI setup tests only two things: slow_odgi (using odgi itself as the differential testing basis) and the Pollen DSL parser (which has RON snapshots of parsed ASTs checked in). It does not cover pollen_data_gen (whose testing setup relies on a baseline that uses odgi's Python bindings, our use of which is going away soon anyway, so it didn't seem worth it).

The only tricky part of this CI setup was running odgi, without compiling it from source (which would be real slow). What I ended up doing was using a preexisting Docker container for odgi. So whenever our tests would invoke a real odgi binary, they instead do docker run odgi.

[anshumanmohan]

🤩

[anshumanmohan]

Nice, this feels a lot like our Dockerfile. Which is a good thing. In fact maybe in the future the Dockerfile should learn from your system of sourcing and running odgi.

[sampsyo]

Yeah, totally. I stole some of the stuff directly from the Dockerfile. Someday merging these things could be cool, but I have never really figured out the way to do this in general for other projects (i.e., to use a "base" Dockerfile twice, once for the "real" Dockerfile and once for the CI).

[anshumanmohan]

Looks great, Adrian. Thank you once again for figuring this out!

[sampsyo]

Excellent; merging this now!