CircleCI integration tests w/o Chef

[lawrencejones]

Remove the dependence on the draupnir Chef cookbook to run integration
tests, vastly simplifying and increasing the speed of running tests from
a local development machine.

This is achieved by using plain dockerfiles and a wrapper in the rspec
test suite to provision a new draupnir instance each time the tests are
run. We also introduce a CircleCI workflow that splits compilation of
the go binary, unit testing of said binary and running rspec integration
tests into separate dependent jobs.

[lawrencejones]

@hmac I'd love a cursory review on this whenever you have the time!

[hmac]

why this?

[lawrencejones]

Specifically the rm? because you want your container to be as small as possible, and this removes all the junk that apt downloads when you interact with the repositories (that you don't need to run your container)

[hmac]

could this not just be cp /workspace/cmd/* /usr/bin/?

[lawrencejones]

I wanted to be specific about what was being copied in, only bringing files across. We can change this though, it probably doesn't get us much.

[hmac]

what else could you bring across that wasn't files? I don't think cp will copy directories without -R

[hmac]

Not a huge fan of having to refer to @draupnir everywhere in specs. Can we not just define the three http methods here?

def client
  @client ||= Draupnir.create_from_container.tap { |c| raise "draupnir did not boot" unless c.alive? }
end

def get(path)
  client.request(:get, path)
end

def post(path, payload, headers={})
  client.request(:post, path, payload, headers)
end

def delete(path)
  client.request(:delete, path)
end

[lawrencejones]

How come you don't like the @draupnir in the specs? Can I argue devils advocate that it makes it very clear from just a glance which parts of the spec are interacting with our test instance?

I'm not attached either way but I slightly favour having one handle to a class, rather than many distinct methods.

[hmac]

It's noisy and unhelpful - the entire test suite involves hitting the service with http calls, so it doesn't distinguish anything. draupnir is also not a helpful name, since it refers to the project as a whole. It'd be like using the variable gocardless in our integration tests.

[lawrencejones]

This also begs the question about how we handle booting and destroying the instance in tests- whether we want to pay the price to boot an instance each time or whether it's best to boot one and deal with it if we break that instance in the middle of a test suite.

[lawrencejones]

That's fair, I think it makes it quite difficult to see what you're actually doing when calling the get/post/delete methods though! Will make the change.

[lawrencejones]

On a side note, I think @draupnir is more honest in how it exposes the underlying mechanism to the test code, in that it makes it clear there is a global handle with state being passed around.

[hmac]

It's a piece of state that doesn't change throughout the lifetime of the test suite though. This is exactly equivalent to spinning up some service (e.g. elasticsearch) before running your integration tests.

[hmac]

very happy to see all this go

[hmac]

and especially this

[lawrencejones]

This is good for a final review now @hmac

[hmac]

Reckon we can do without one of these