We want a check that the build succeeded on GitHub.
Unfortunately, circleci doesn't give us a final result from a workflow.
We hack around it by making one job that does nothing really.
Hopefully they can provide a better interface for this in the future.
It looks like,
when we switch jobs in CI the new checkout has newer timestamps
than what's in the make cache.
Rather than dealing with that anymore, we alter the targets.
We can change `test` to ensure builds are up to date.
Then we can leave the individual test targets to run whatever is there.
In CI this means we can set the workflow to run the tests separately.
If we don't do this, the test job will try to rebuild everything.
That defeats the purpose.
Probably, we've got our Make dependencies/targets setup improprerly.
I had an older version of `cabal`.
It didn't check that the `description` was longer than the `synopsis`.
The `cabal` on CI is newer.
It would be nice if everything used the same programs.
Might look into using a specific `docker` image or `nix` for this.
Since we use `stack` to run `hpack` to generate the cabal file,
we need `stack` to have its cache all setup properly.
We could eschew `hpack` to relax this requirement...
While it would be really nice to run this from CI,
The only way to upload a package involves using account-wide credentials.
We can either use a username/password, or an API token.
Both of these credentials have the same privileges,
and that's too much power to give to CI.
For now, we run this from the local machine.
Maybe we can think of another way that's a bit safer.
We don't really need to have separate caches.
We fallback to the stack-root cache as it should have built most stuff.
We can remove it in a future commit.
It will have cached under the new key.
We also can call one command, and let Make figure everything out.
This is almost entirely copy-pasted from `wai-middleware-rollbar` 0.8.4.
The intent is to make the core data types available for other packages.
If this gets unweildy, move it right back.
