Fork me on GitHub
#boot
<
2015-08-17
>
avery00:08:03

Anyone aware of a clojure.test → Junit XML output task for boot?

mitchelkuijpers11:08:43

Sooo... I am creating uberjars with boot and it's slooooowww (which is a known problem I know) how do you guys deploy to AWS?

martinklepsch11:08:44

@mitchelkuijpers: currently building uberjars as part of CI but I think in near future I’ll move to just running things with boot in production

martinklepsch11:08:02

that said it still would be nice if uberjar building would be as fast as it is in lein

mitchelkuijpers11:08:55

@martinklepsch: true I saw some talk of adding it to the jar task, I think while not as idiomatic it would be a good solution

alandipert13:08:25

@mitchelkuijpers: most of our stuff is beanstalk+docker and in our docker file we run the boot entrypoint (no servlet container)

alandipert13:08:51

this is nice because the boot runtime (pods) are available at runtime

alandipert13:08:02

@mitchelkuijpers: are you using tomcat on beanstalk or something different?

mitchelkuijpers13:08:01

@alandipert: We are currently creating our deployment, we are checking if we would like to run on beanstalk or spin up a ec2 instance ourselve

mitchelkuijpers13:08:18

Creating an uberjar takes a while but for the rest it is running absolutely fine

mitchelkuijpers13:08:29

but do you guys just download all dependencies when deploying on the instance?

alandipert13:08:42

that’s the docker way

alandipert13:08:12

when deploying to a servlet container, the way to go is with the —as-jars option to uber

alandipert13:08:23

that leaves the unpacking of the jars to the servlet container and is pretty snappy

alandipert13:08:42

but if you want to be on AWS with boot for a web service, i personally think docker on beanstalk is the way to go

mitchelkuijpers13:08:44

Aha we don't want to deploy on a servlet container, because we are using catacumba

mitchelkuijpers13:08:53

so we need to run a jar

alandipert13:08:07

here is one of our latest Dockerfiles for a boot web app: https://gist.github.com/alandipert/3d39b47ce7bc320f3a01

martinklepsch13:08:29

@alandipert: out of curiosity, how do you handle image building/storage?

alandipert13:08:54

we don’t, yet… ultimately we want to run our own docker registyr

alandipert13:08:32

private image storage notwithstanding, i think docker has been a win if only because it helps so much with reproducibility

alandipert13:08:51

like everyone on the team has working docker knowledge, and can get every app at least started

mitchelkuijpers13:08:11

We also have the problem that we need to compile our cljs, I would like to do that only once and not on every machine that we start

alandipert13:08:21

that and deployment flexibility… we stood up dokku on an EC2 recently for little things like slack hooks

mitchelkuijpers13:08:01

@alandipert: I see you guys have an m2 proxy where you download the deps from that fixes losing dependencies

alandipert13:08:17

yeah we’ve been running nexus for that, not super happy with it… been working on http://projars.com/ on the side

mitchelkuijpers13:08:43

We also run nexus, it works pretty much for us

mitchelkuijpers13:08:47

Ahh well for now we'll simply go for the simple route (an uberjar) for us. Might have to take a look at docker later on. Thanks for the example @alandipert

alandipert13:08:11

@mitchelkuijpers: no prob! yes i hope this week to stand up a “Deployment” wiki page, i’m not sure the various options have been enumerated anywhere

alandipert13:08:08

uber might not be so slow soon, last week micha and i paired on a ‘caching-uber’ branch, which bypasses the slow parts of fileset for files that don’t change

martinklepsch13:08:27

@mitchelkuijpers: for cljs deployment I’d recommend CI pushing to S3 and then serving through CDN

danielsz13:08:25

@alandipert @micha: I have some time to hack on boot, specifically https://github.com/boot-clj/boot/issues/255.

danielsz13:08:24

@alandipert: When you push that wiki page on deployment, I'll add a paragraph on boot-runit, the deployment strategy I've been using the last year

alandipert13:08:13

@danielsz: that sounds great, feel free to start it

martinklepsch13:08:58

@danielsz: we’re currently using upstart, I briefly searched for a comparison etc, can you point me to something that tells me why I should use runit?

danielsz13:08:03

@martinklepsch: Oh, with great pleasure. You'll find runit advocacy on the accompanying blog post: http://danielsz.github.io/2014/12/06/lein-runit/

danielsz13:08:40

But in one borrowed paragraph: Dan Bernstein (of qmail fame) wrote the seminal process supervision toolkit daemontools, which is a beautifully-designed set of small, ultra-reliable and highly-specialised programs that cooperate in the UNIX tradition to manage process supervision trees. Runit is a more conveniently licensed and more actively maintained reimplementation of daemontools, written by Gerrit Pape.

martinklepsch13:08:55

I’m past that paragraph 😛

danielsz14:08:59

@martinklepsch: And this one? The beauty of runit is its brevity and simplicity: the runsv command, which manages each process, is only 600 lines of code. In this post I want to explain how runit works and why I’m so impressed.

malcolmsparks14:08:22

is it possible to develop boot tasks without having to ship them as libs - I'm finding the dev workflow really painful. I want to use some functions of boot.core but it doesn't seem to be accessible at all - all the examples on the web are trivial and use clojure.core, but I'm trying to write filesets etc.

martinklepsch14:08:04

@malcolmsparks: you can require boot.core in any namespace

malcolmsparks14:08:47

I must be doing something wrong, it just isn't letting me require boot.core

malcolmsparks14:08:01

perhaps I need to declare a 'boot src' dir or something

martinklepsch14:08:20

@malcolmsparks: is your namespace in :source-paths?

malcolmsparks14:08:36

:source-paths #{"src"}

martinklepsch14:08:36

and do you get an exception requiring boot.core or what exactly happens?

malcolmsparks14:08:21

I've created a ns, juxt.stencil:

malcolmsparks14:08:22

(ns juxt.stencil (:require [boot.core :as c])) (c/deftask gen [] (let [tmp (c/tmp-dir!)] (fn middleware [next-handler] (fn handler [fileset] (c/empty-dir! tmp) (let [fs' fs] (next-handler fs') )))))

malcolmsparks14:08:44

in my build.boot I refer to it

malcolmsparks14:08:51

(deftask gen [] js/gen )

malcolmsparks14:08:54

but when I boot gen

malcolmsparks14:08:09

[malcolm@tulkas website]$ boot gen clojure.lang.ExceptionInfo: No such var: c/tmp-dir! data: {:file "juxt/stencil.clj", :line 6}

malcolmsparks14:08:39

I'm sure I'm doing something wrong 😞 but really appreciate you trying to help @martinklepsch

martinklepsch14:08:54

We’ll have this sorted in 5min

martinklepsch14:08:12

there’s the culprit

malcolmsparks14:08:34

I installed boot ages ago, just picking it up again

martinklepsch14:08:44

update boot 1. update binary 2. boot -u

malcolmsparks14:08:47

i'll try upgrading, thanks very much

juhoteperi14:08:32

temp-dir! was renamed to tmp-dir! in boot 2.0.0

malcolmsparks14:08:35

great, thanks @martinklepsch , that was the problem, I'm out of the rut simple_smile

malcolmsparks14:08:01

(-> fileset
          ((partial reduce core/add-asset)    (map io/file add-asset))
          )

malcolmsparks14:08:27

some of these bootisms are very cool - took me a while to grok what was going on here but once I got it I smiled simple_smile

malcolmsparks14:08:51

map/reduce ftw

juhoteperi14:08:44

Hah grok is a great word

malcolmsparks14:08:56

I'm actually writing a boot task to generate content from mustache templates - does anyone here know of something that already does that? it must be a common need - if not, i'll publish

malcolmsparks14:08:12

@daraen thanks

tel21:08:12

Is there a way to get reload to hit different jsload targets depending on the build

tel21:08:32

e.g. to re-run my test runner in the test build and to reload my page in the dev build

juhoteperi21:08:29

Maybe using ids filter (in snapshot)

tel21:08:13

I start two reloaders, one for each build?

tel21:08:00

yup, I do, and that works great