boot

:boot-clj: https://boot-clj.github.io/ — build tooling for Clojure. Dev chat in #boot-dev
danm 2018-05-24T15:28:00.000390Z

So, when I do a boot build on a new host (which we get quite often on our Jenkins box as it redeploys regularly and doesn't have persistent disks) it seems to pull down every version (including alphas etc ) of Clojure from 1.4.0 up to 1.10.0-alpha4. This despite there being a boot.properties in the directory boot is being run from which specifies BOOT_CLOJURE_VERSION=1.8.0, and build.boot specifying (set-env! :dependencies '[[org.clojure/clojure "1.8.0"]])

danm 2018-05-24T15:28:13.000144Z

Is there any way to stop that, and get it to just pull down the Clojure version we want?

alexmiller 2018-05-24T15:30:31.000309Z

is it pulling the poms or the jars?

alexmiller 2018-05-24T15:30:52.000938Z

Maven will sometimes pull poms to determine metadata (to do version resolution)

danm 2018-05-24T15:31:53.000983Z

Aah, good point. It is pulling down the poms. It just seems to take a surprisingly long time to get each one even though they're only 2-3K apiece

2018-05-24T16:38:18.000257Z

2 ways to speed it up that come to mind are 1) persist ~/.m2 across builds and 2) run sonatype nexus with a proxy repository near or on the jenkins box

2018-05-24T16:38:41.000839Z

although 1) adds brittleness and 2) is kind of a pain

2018-05-24T16:39:36.000593Z

to alleviate 1) you could run 2 builds, one that uses shared m2 and runs quickly (like maybe for smoke tests) and a second longer-running build that starts with fresh m2

mccraigmccraig 2018-05-24T17:14:35.000469Z

we persist ~/.m2 in our cloud CI setup - haven't had any problems with it in the year or so it's been up and running

dave 2018-05-24T17:25:12.000342Z

speaking of caching ~/.m2, i've been playing with AWS CodeBuild lately and getting good results by doing that

dave 2018-05-24T17:25:21.000561Z

i was actually curious about caching the boot cache too... is that a good idea?

dominicm 2018-05-24T17:52:38.000163Z

@dave we do that on circleci, I see no reason it's not equally applicable.

dave 2018-05-24T17:54:13.000386Z

nice! good to know!

danielcompton 2018-05-24T20:54:46.000601Z

Yep, the .m2 directory is eminently cacheable. The only place I could see issues if you are saving the cache after installing your project to the m2 cache, especially if it wasn't installed as a SNAPSHOT version

dave 2018-05-24T21:04:14.000260Z

that makes sense -- if your build includes installing arbitrary stuff to your .m2, you are messing with what is otherwise conceptually a collection of immutable artifacts

dave 2018-05-24T21:05:06.000230Z

i guess if your application depends on SNAPSHOT versions of things, another caveat of caching .m2 is that you won't get updated snapshots. but maybe that's OK

alexmiller 2018-05-24T21:49:14.000350Z

yo, I heard immutable append-only data stores were imminently cacheable

alexmiller 2018-05-24T21:49:37.000308Z

someone should make a db like that

😂 1
dave 2018-05-24T22:06:36.000390Z

💡