This also switches back to building both libs together to not require splitting pull requests into -core and -remote related ones and releasing -core first (and then re-submitting the -remote PR) if we need changes to both of them which puts additional burden to contributors and maintainers. The interaction of both can be handled by upper bounds easily or we release both at once iff needed.
I've had to disable io-testsuite of remote for now #222 which I'll investigate later.
Rework CI to use https://github.com/sorki/github-actions-dhall/ which was suggested couple years ago by @sjakobi
The original https://github.com/vmchale/github-actions-dhall is not actively maintained so I maintain a fork with updated
haskell-ci.dhallsince then and it is working quite well in numerous projects (another TODO for me to make it a proper fork with onlyhaskell-ci.dhalland maybenix-haskell-ci.dhall.. https://github.com/sorki/github-actions-dhall/issues/3).This also switches back to building both libs together to not require splitting pull requests into
-coreand-remoterelated ones and releasing-corefirst (and then re-submitting the-remotePR) if we need changes to both of them which puts additional burden to contributors and maintainers. The interaction of both can be handled by upper bounds easily or we release both at once iff needed.I've had to disable
io-testsuiteof remote for now #222 which I'll investigate later.cc @domenkozar