Fork me on GitHub
#boot
<
2018-05-24
>
danm15:05:00

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"]])

danm15:05:13

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

alexmiller15:05:31

is it pulling the poms or the jars?

alexmiller15:05:52

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

danm15:05:53

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

alandipert16:05:18

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

alandipert16:05:41

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

alandipert16:05:36

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

mccraigmccraig17:05:35

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

dave17:05:12

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

dave17:05:21

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

dominicm17:05:38

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

dave17:05:13

nice! good to know!

danielcompton20:05:46

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

dave21:05:14

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

dave21:05:06

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

alexmiller21:05:14

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

alexmiller21:05:37

someone should make a db like that