Fork me on GitHub
#boot
<
2018-03-12
>
qqq05:03:39

$ env | grep BOOT
BOOT_JVM_OPTIONS=-Djava.library.path=/usr/local/cuda/lib64 -XX:-OmitStackTraceInFastThrow
$ cat .bashrc | grep BOOT
export BOOT_JVM_OPTIONS='-Xms36G -Xmx120G -Djava.library.path=/usr/local/cuda/lib64 -XX:-OmitStackTraceInFastThrow'
Why are the -Xms and -Xmx beings tripped off ?

martinklepsch07:03:18

not sure, have you tried sourcing .bashrc and then immediately inspecting env? maybe something else is changing the env var?

alandipert15:03:27

maybe boot repl -e would be a way to run the code you want

alandipert15:03:03

another way that comes to mind is a a ci.boot file that does (load-file "build.boot") ... your custom ci-only code

alandipert15:03:17

then boot -b ci.boot

alandipert15:03:01

oh you know what

alandipert15:03:07

i forgot, tasks can be ns-qualified

alandipert15:03:58

boot -d boot-codox codox.boot/codox -h

alandipert15:03:13

still possible to overwrite the codox task in its home ns but would require some real initiative of the build.boot author

michal16:03:15

@alandipert thanks Alan, using ns-qualified tasks would solve that problem perfectly, but I just realised that it doesn't really have a much sense, because entire build.boot is evaluated at the beginning, so no matter what sits in the task I'm calling, malicious code may be placed literally everywhere as a top level expression.

michal16:03:54

seems like calling boot task in an isolated container would be the only secure option.

alandipert16:03:28

and then not even, i don't think pods can be considered "secure"