Fork me on GitHub
#boot
<
2016-03-21
>
tcrawley15:03:31

I see that the repl task can take a pod name to run the repl in, but what's the proper way to name a pod I create?

tcrawley15:03:43

it doesn't appear to be an option to pod/make-pod

tcrawley15:03:05

is (doto (pod/make-pod opts) (.setName "foo")) acceptable?

alandipert15:03:32

@tcrawley: i think so. altho i wonder if we shouldn't have a boot.pod/set-name! function also

tcrawley15:03:36

that would be swell, but I'm fine with .setName, just wanted to make sure there wasn't a better way

micha15:03:58

2.6.0-SNAPSHOT has a more clojurey way

micha15:03:31

i think...

micha15:03:22

(boot.pod/pod-name the-pod "new-name")

alandipert16:03:03

ah that makes more sense than set-name! which would promote renaming, which is probably not good

nberger20:03:30

Has anyone ever got "java.io.IOException: User limit of inotify watches reached" when running a boot task? I get it from time to time in CircleCI. Never got it locally

nberger20:03:47

sudo cat /proc/sys/fs/inotify/max_user_watches shows 8192 in both my env and in circle

nberger20:03:02

I'm going to create a support ticket in circle, but wanted to share it here too, in case anyone has already gone through it

alandipert20:03:17

is there a way to run stuff as root in circleci? that would be another workaround

nberger20:03:09

what would be the workaround? to increase the watches limit?

nberger20:03:34

I thought about it, but I'd like to first try to understand why it happens...

alandipert21:03:44

the workaround would be that root isn't ulimited

alandipert21:03:11

hm, i think i could be wrong about that

alandipert21:03:45

and you're not using the watch task in this build?

nberger21:03:50

ok simple_smile anyways, I'd like to avoid having to run as root

juhoteperi21:03:34

sudo should be available and increasing the limit is good fix

nberger21:03:36

No, I'm not using watch task in this case

juhoteperi21:03:01

using 100k limit on my computers, I have hit the limit some times by running multiple boots

nberger21:03:13

So even when not using the watch task, boot would "use" a lot of inotify watches?

nberger21:03:23

oh, good to know

juhoteperi21:03:19

Could be related to number of directiories in source dirs, IIRC inotify is not recursive so each directory needs a watch (I could be wrong)

nberger21:03:08

cool, thanks for the info! I guess I'll end increasing the limit

juhoteperi21:03:18

Or could be related to how watch is implemented by Java NIO

nberger21:03:01

also, being a virtualized environment, I'm really not sure if I'm not affected by "bad neighbors" who might also create a lot of watches... and not sure if I want to know, perhaps it's better to just increase it 😛

juhoteperi21:03:30

I think the watches are local to container, and CircleCI creates "new" container for each build

micha21:03:30

boot installs the fsevent inotify watches so it can keep track of the source files in your project

micha21:03:42

because when those change it needs to copy them into the fileset and onto the classpath

micha21:03:04

like consider the case where you're just doing boot repl

micha21:03:11

and you update a file in your project

micha21:03:30

boot needs to update that in the classpath so you can do require :reload on it

nberger21:03:30

cool, thanks

nberger21:03:00

not sure though what's different in circle that makes it to reach the limit there, while it doesn't reach it in my machine, but I think I'm fine with having that unanswered simple_smile

juhoteperi21:03:29

Not sure if it possible to get list of watches but using kernel tracing it is possible to get count of watches created

juhoteperi21:03:42

And starting a Boot project created 70 watches for me

micha21:03:07

@juhoteperi: you're right about the recursive thing

micha21:03:23

boot needs to make a new watch manager thing for each directory

micha21:03:32

and each subdirectory etc

juhoteperi21:03:19

Okay. Large directory tree (like node_modules) will then easily use 8k limit,

micha21:03:48

man, maybe we should use the checkout task

micha21:03:56

to zip node_modules up intoa jar

micha21:03:09

i think that could be done, and it would speed upa lot of things

juhoteperi21:03:38

Or just don't use node_modules simple_smile

micha21:03:42

well yeah lol

micha21:03:46

maybe that's the way to deal with large file trees, though

micha21:03:04

have some automated way to make a temporary jar of them

micha21:03:09

or something

micha21:03:40

then you could use the sift task to extract only the ones you are working on and put them into the fileset

micha21:03:07

i'm thinking like scss stuff maybe, or something like that

micha21:03:23

where you actually work on only a few files, but there are a ton of resources