Lets have a CI, so it builds and tests stuff

[Anton-Latukha]

In HNix I banged-out some pretty portable setup for Haskell:

it consists of:

1. https://github.com/haskell-nix/hnix/blob/master/default.nix which exposes Nixpkgs haskell.lib API.
2. https://github.com/haskell-nix/hnix/blob/master/build.sh which exposes Nixpkgs haskell.lib API.
3. https://github.com/haskell-nix/hnix/blob/master/.travis.yml which exposes .., you know the shtick ...

That resulted in: https://travis-ci.org/github/haskell-nix/hnix

Which helped to have and keep proper cabal sdist.
And strict build on GHC 8.6.5 currently. So no no warnings in PRs.
Also Hackage Matrix: https://matrix.hackage.haskell.org/#/package/hnix

CI even does GHCJS build with Cachix.

I and Nix already made fell on all rakes we had, so everything is ironed-out now.

---

What do you think?
We can easily migrate this CI setup to GitHub Actions, I would be up for it.

[sorki]

Thank you for all the work on this!

I'm weakly against switching to GitHub Actions as it feels kind-of unfair to Travis and further locks projects on GitHub.

I'm quite biased on this though as I'm working on a CI built on top of nix/hnix that is hosting platform agnostic and most importantly allows self-hosting. It's not quite ready yet - I'll add a proposal to haskell-nix/hnix#593 when I manage to iron out last few issues.

[Anton-Latukha]

"Unfairness" to Travis I do not feel anymore.

Travis CI is a project of a company, which owners sold everything to the cynical firm, which right-away fired almost all workers including majors/creators of Travis CI project.

Be "loyal" to Travis CI at this point. Travic CI is the empty proprietary brand name at this point. Almost like believing the lies that real Atari still exists.

If we to look at: https://github.com/travis-ci/travis-ci, we see that they are closed public support, direct community into self-help forum, and direct bugreporting to support@travis-ci.com, with is hardly an open approach.

If we would compare Travis CI and GitHub CI now - there is no difference or even morally contrary difference, both company services, with the difference that Travis CI is a service brand name and owners do not care about its members, while Microsoft, in fact, has a much better reputation now and cares about GitHub and products and has much more lavish abilities and generosity of the CI. Their CI is way powerful, modern, and backend may be well, probably, in Haskell. And GitHub CI now has more flexibility and abilities, power in comparison.

For me, default.nix, build.sh is really the majority of the code, it can be easily ported to any "classical" CI. Also as SRE/DevOps I know the difference between CIs, Travis CI is very cookie-cutter CIs, it really can not be programmed and lacks functionality and flexibility of "real CIs" and so their possibilities. Own build CI, Jenkins, TeamCity, GitLab CI, Hydra CI (which I worked with) are straight-away much richer in their abilities and so development process effectiveness.

Travis CI is basically a history of ten years past, its creators should be remembered for its kindness and generosity, and that story is over for several years, the project was sacrificed fully.

[sorki]

Unfairness not only to Travis but the rest of the ecosystem around GitHub API I would say (although users of that can quickly provide Actions instead interfacing with their own services like e.g. Cachix does).

I'm not a big fan of Travis either (nor GitHub anymore for that matter) and exactly like you say Travis is not flexible enough for building automation on top of it.

I've used to run production Jenkins instance, Hydra, Scylla CI and now I'm getting back to running things on top of post-receive hooks with lightweight and composable tooling built around that + nix + udate-nix-fetchgit. The reasons for that is not to be tied to e.g. running shell scripts, being able to fix the CI when it breaks, ability to tailor it to specific use-cases - well TLDR opensource.

I've started building this few years ago while I was still using RPM but the scope quickly got too large due to need for bootstrapping, sandboxing and distributing builds - with Nix most of this is not needed which makes it reasonable scope-wise and I'm already running beta version of this for another project of mine.

[domenkozar]

With https://github.com/input-output-hk/haskell.nix and https://github.com/cachix/cachix-action you'd have a working CI with a few dozen lines of code :)

[Anton-Latukha]

CI is at: #69

CI builds of it of master hnix-store are tracked at: https://github.com/Anton-Latukha/hnix-store/pull/1/checks

[Anton-Latukha]

Classic Hackage Cabal builds: #88

[Anton-Latukha]

WIth cabal and nix-build added - consider the basics of CI are provided.