Deploying Shake in intranet scenarios

Question

I have finished writing a shake-based build system and have reached the deployment stage.

Is there any resource on best practices for deploying Shake-based build systems in intranet scenarios? I'm concerned about things like reproducing a build 5 years from now, whether plain cabal or stack would be a better fit to build the build system itself, how to track the build system dependencies given there's no internet access...

In order to reproduce a build, I'm considering something like generating a Makefile (easy with my approach) prior to tagging a release, and resort to make for building at points that fail to build using the latest shake version. That would avoid storing copies somewhere of all the dependencies used by shake itself over time, but I was wondering if there're better approaches.

Answer 1

For reproducing builds and the build system, the best way to go is a virtual machine image in which you have the OS, along with all things you might otherwise fetch from the web - e.g. Haskell libraries off Hackage. That should give you 100% reproducibility, and is project/language agnostic.

If you want to avoid a complete VM for a Haskell project, the next-best thing is a stack.yaml file, which specifies a given package set, and thus fully ties down every package version, so will stick to an old version of Shake.

Since Shake is much newer than Make, and has a much larger API, it is inevitably going to change more than Make, and will have breaks that mean your old code will not work anymore indefinitely (hopefully rare, hopefully easily fixable). In contrast, Make has been very stable for decades, so a Makefile backup is probably useful to have if it's cheap to create.