Setup CI workflow

[zharinov]

I would like to discuss setting up Github Actions (via setup-clojure) for testing on matrix of setups and maybe additionally using Cirrus CI for building executables, e.g. for Apple M1 chips.

This is the something I would like to work on.

[kkinnear]

Hello! Thanks for the Issue and PR!

I have several of questions for you:

1. Are you a current user of zprint?
2. Are you thinking of doing one or two PR's to contribute to zprint's testing, and then move on. Or are you looking to have a longer term connection to your contribution(s)? Another way of asking this is: Are you planning to maintain your GitHub Actions contribution over time, or are you expecting to get it working and then I'll be maintaining it over time?
3. Why are your offering this contribution to zprint? Possibilities: You have lots of experience with GitHub Actions and would like to see more people use it? You use zprint and would like it to be better tested? Something else?

Thanks!

For may part I'm certainly interested in getting zprint more involved with Github Actions. The biggest thing I need is to have some way to build the graalVM zprintl release binary for Intel Linux. I'm currently doing that on an old 2012 MacBook Air laptop that I keep around for just that reason. I build the MacOS version with graalVM in a newer M1 MacBook Air, but I build it for Intel and it works well enough. I haven't actually tried the newer graalVM that will build M1 specific binaries.

My current workflow is (largely) to get a new release ready, test it with both Clojure and Clojurescript tests (about 1500+/- for each). I also have a test_config which does some extensive testing on the uberjar, and zprintm- and zprintl-. Then I do a bunch of by-hand testing of Figwheel, shadow-cljs, planck, clj, and a local version of cli-doc. Then I push the source to GitHub and transfer the release binaries to the GitHub "release". I don't actually push code until I'm finished with a release (though I did recently push another branch for someone to try something, but that is unusual). All of this testing is on MacOS, except I do also run a test_config on Linux. For what it is worth, test_config is truly a terrible hack, though it is valuable nonetheless. It needs to be rewritten in Clojure using babashka, but I haven't gotten around to that yet.

The tests in zprint/test/... are mostly not unit tests, but pretty much tests for the specific aspects of zprint library itself. The test_config tests are tests of the uberjar and graalVM binaries, things that can't be tested with the library itself.

Having the zprint/test/... tests and the test_config tests run on additional platforms (or in additional environments) would be wonderful. Equally wonderful would be to automate the Figwheel and shadow-cljs tests. The planck tests could be automated too, but there is less urgency to that since the zprint/test/... tests use planck for the Clojurescript part of the test, so if the CLJS tests pass, then planck must not have trouble with zprint. Rewriting the test_config tests in babashka would be wonderful too, but that isn't directly a GitHub Actions thing.

I haven't yet looked at your PR yet (and since I've never used GitHub Actions, I'm not sure what I'll take away from it when I do). I will do that directly.

Thank you very much for your contributions so far and your future discussion of the possibilities!

[zharinov]

Thank you for quick response, and let me answer your questions:

1. I'm using zprint instead of code formatting facility provided by Cursive IDE, though have no big Clojure projects
2. I've subscribed to zprint repository and I'm planning to react if something will go wrong
3. I see great potential for the tool you've created and would like to see more people using it, e.g. with setup-clojure GitHub Action. But more usage means more issues, and more issues means more changes. In order to make these changes effectively for you and for any other contributor, it will be helpful to have build pipeline set up. So here we are.

Being put it in more global context, I would like to improve continuous integration story for the Clojure library ecosystem by reducing excessive friction to set it up. It definitely isn't the most fun part comparing to actual coding with REPL, but I believe it's essential for any code of high enough complexity and quality.

[zharinov]

Also, please feel free to reach me in Clojurians Slack by the same username I use for GitHub