This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-27
Channels
- # beginners (22)
- # boot (652)
- # boulder-clojurians (1)
- # cider (19)
- # cljs-dev (3)
- # clojure (158)
- # clojure-dev (8)
- # clojure-nl (1)
- # clojure-poland (5)
- # clojure-russia (27)
- # clojure-sg (3)
- # clojure-za (4)
- # clojurescript (44)
- # community-development (2)
- # core-async (17)
- # core-logic (10)
- # css (1)
- # cursive (35)
- # data-science (5)
- # datascript (1)
- # datomic (90)
- # editors-rus (3)
- # events (3)
- # hoplon (90)
- # ldnclj (19)
- # lein-figwheel (2)
- # leiningen (1)
- # om (225)
- # reagent (1)
- # uncomplicate (27)
any luck?
@alandipert: can you try that one?
i can in a few mins
yeah i'm not a fan of the global exclusion
if you add like, dunaj tho
so maybe your BOOT_CLOJURE_NAME is dunaj and a dep brings in clj
true, but this would still be new behavior for you
if BOOT_CLOJURE_NAME is dunaj it wouldn't change anything about clojure deps, i don't think
oh now, but the problem may exhibit itself, no?
oh i suppose it won't be clojure.lang.Compiler$Expr
so it's good-ish
yeah not cool man
compiled with java 7, right?
i need to do dishes but after that
i can plug in and turbocompute
bump the com truise
ok later
i'll be able to
ok yeah
me too, finally
i'm trying to get java 7 going
i can only remember how to maintain multiple JDKs on 2 OSes at a time
but i'm on the one that was not cached in my brain
oh yes
all of them are
jar, javap, etc
tons of crap in the jdk bin
oh wait, wrong talk i think
i could swear there's another one where he talks about jvm debugging
that one is nice coverage of invokedynamic tho
@martinklepsch: feel free to open that brew PR again at your leisure, 2.4.1 is good
@micha: Should boot.App be available in all pods?
Hmm, I guess the problem is that boot/aether doesn't depend on boot/base
Adding dependency to boot/base (with provided scope) to boot/aether seems to work
I had to remove ~/.boot/boot.properties to get Boot working at all after updating to 2.4.1
And now I'm getting exceptions like: java.lang.NoClassDefFoundError: clojure/lang/AFunction
and java.lang.NoClassDefFoundError: clojure/lang/RT
Anyone know what issue this indicates:
clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Unable to resolve symbol: intern in this context, compiling:(/var/folders/rj/8lnf662s3mlgzv5mcq2r2fnc0000gn/T/boot.user250642385654527633.clj:1:715)
?I get it when I run the repl
task
@pesterhazy: what version? haven’t seen it before — is there a intern
symbol in your build.boot?
is that all you got or are there more lines?
git grep intern
has no matches
nothing more in the output
I had this once when there was a mistaken ns declaration.... I think
my.project.foo vs my/project/bar.clj
I see. How about bisecting then?
it's strange
it's now fixed; I looked at the git log
and I only see the fixed ns declartion
declaration
I must have made a mistake somewhere
still, that is a strange error
Clojure often behaves weird if there's a (ns)
vs filename mismatch
I'll bring it up if I see this again
@pesterhazy: did someone else fix it or what happened that it now works?
Seems to be similar to what @juhoteperi reported but removing boot.properties didn’t change the outcome.
Yeah, removing boot.properties didn't fix that. But before removing it, boot didn't start at all for me.
@juhoteperi: I noticed that when you set BOOT_VERSION to something else then 2.4.1 it just doesn’t do anything — is that what you mean?
@martinklepsch: no, I "fixed" it
@micha: @alandipert 2.4.{0,1} is really strange to me. We should have tested this more. What do you think about rolling these two commits back and releasing a 2.4.2 with only the stuff before micha’s classloader stuff?
yeah, if I s/2.2.0/2.4.1/ in boot.properties
, boot dev
just doesn't do anything anymore
or is that not how I update boot?
@pesterhazy: sometimes (as with 2.4.{0,1}) you need to also download a new binary. 2.4.0 was supposed to be the last release that requires a new binary update. 😄
what is the state of 2.4.1? i'm seeing something very weird where it looks like tasks in our CI are running twice per invocation
@pandeiro: with 2.4.1?
do you have a boot.properties file? calling boot -u
?
If I specify a boot-core version in build.boot
would that prevent Boot from retrieving and using 2.4.1?
@pandeiro: BOOT_VERSION
is supposed to handle that, are you sure that env var is properly exported on CI?
@pandeiro: CircleCI? maybe ssh & boot -V
could give some hint
@martinklepsch: the boot.properties
file is at the project root where boot ...
commands are run -- would I need to do something more than that?
I cleared the CircleCI cache, so I assume that is why it is retrieving those latest versions of the libs
But if my :dependencies
specify a version of boot, will it peg to that version of boot, pod, aether etc?
@pandeiro: no that sounds right. are you running boot -u
?
hm. the :dependencies
thing should really not be necessary and I’m not sure if it’d help. only thing I can think of for troubleshooting is boot -V
besides that I have no clue why tasks would run twice in 2.2.0 or 2.4.1
@martinklepsch: but the expected behavior of boot is to download the latest versions of the libs if none are present yet in the local maven cache, right?
or the ones specified via BOOT_VERSION
. usually your project should not have a dependency on boot. maybe some of your deps imports it?
i'm less worried about the tasks running twice (maybe just outputting twice -- could be a buggy circle ui too) but more about how i can specify and control which boot lib versions are obtained
do any boot (aether/pod/worker/core) deps show up in boot show -d
?
are you sure BOOT_VERSION=2.2.0
for example means boot binary and libs version 2.2.0? I'm thinking it just means the binary?
no it definitely means libs. can you check boot -V
? I’m thinking maybe it just downloads the deps but doesn’t use them? … similar to how boot show -u
acts
#
#Tue Oct 27 09:35:47 BRST 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.2.0
#App version: 2.2.0
is that from CI? if so I’m pretty sure no other deps then 2.2.0 are being used. Still weird that it downloads latest though.
what would happen if boot.properties
specifies a BOOT_VERSION
lower than the version of the binary that was downloaded? Any idea?
binary version can’t be changed via BOOT_VERSION so it would still be whatever version the binary is that you downloaded
so one issue is that a different version was being specified in circle.yml
boot install step than in boot.properties
...
And it does seem that when those two don't match, it retrieves boot 2.4.1
and I get the double output issue (even with boot -V
etc)
that sounds strange what version did you download and which did you specify in boot.properties?
my local version is still 2.2.0; a recent update to our circle stuff made the install retrieve 2.3.0. properties version has always remained 2.2.0.
But don't worry about it @martinklepsch -- I think I'm just having a twilight zone moment here...
I’d wait. I’ll try to reproduce your issue and log an issue if I can.
we should establish some testing process to avoid this in the future
@micha: two things 1) boot $task returns without any output 2) https://github.com/boot-clj/boot/issues/321
@pandeiro: what tasks did you invoke that caused duplicate output? any? even boot -V?
@martinklepsch: yes even boot -V
, boot show -d
, as well as project-specific tasks
/v/f/s/4/T/boot-test> boot220 -V
#
#Tue Oct 27 12:59:37 CET 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.3.0
#App version: 2.2.0
the combination was: binary 2.3.0 installed; BOOT_VERSION 2.2.0 specified; empty ~/.m2/repository
oh, other way around ;D
@martinklepsch: feel pretty confident now that installing boot and then running a command with an empty maven will cause boot to download the latest version of the lib
Additionally, I'm getting The command '/bin/sh -c boot -vv' returned a non-zero code: 254
in Docker Hub and Travis builds that bring in 2.4.1
maybe since i'm trying to publish a 2.3.0 image, I could change that step to boot -d boot:2.3.0 -vv
... I wonder if that would work
I’m confused:
~/c/d/boot-test2 rm -rf ~/.m2/repository/boot/
~/c/d/boot-test2 boot230 -V
#
#Tue Oct 27 13:21:33 CET 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.2.0
#App version: 2.3.0
~/c/d/boot-test2 boot230 show -d
Retrieving pod-2.2.0.jar from
Retrieving core-2.2.0.jar from
Retrieving worker-2.2.0.jar from
I get "Retrieving boot-2.4.1.jar from ..." and then the additional deps are 2.2.0 as well, like yours
@pandeiro: afaik boot-x.x.x.jar is just to get some sort of fake clojars transaction
Hmm, my boot -d boot:2.3.0 -vv
idea above didn't work... It still gets 2.4.1 versions
it’s what the binary checks for new releases and during deploy it’s uploaded after all other jars
The scenario I mentioned above (binary 2.3.0, version 2.2.0, empty cache) produced this:
$ ./bin/circleci-deps
Retrieving boot-2.4.1.jar from
Retrieving clojure-1.7.0.jar from
Retrieving dynapath-0.2.3.jar from
Retrieving pod-2.2.0.jar from
Retrieving shimdandy-impl-1.1.0.jar from
Retrieving core-2.2.0.jar from
Retrieving aether-2.2.0.jar from
Retrieving worker-2.2.0.jar from
Retrieving parsley-0.9.3.jar from
Retrieving regex-1.1.0.jar from
Retrieving reply-0.3.5.jar from
Retrieving cd-client-0.3.6.jar from
Retrieving clj-http-lite-0.2.0.jar from
Retrieving slingshot-0.10.3.jar from
Retrieving clj-stacktrace-0.2.7.jar from
Retrieving drawbridge-0.0.6.jar from
...
@micha: as for rolling back I made a test with all commits until the new binary stuff and that seemed to work fine
I just followed https://github.com/boot-clj/boot/wiki/Cider-REPL and get a stacktrace when running boot repl
Is that a known issue?
clojure.lang.ExceptionInfo: java.lang.NoClassDefFoundError: clojure/lang/RT, compiling:(deps/toolsreader/v0v9v2/clojure/tools/reader/impl/utils.clj:1:1)
@ska: it is, and it's new... we pushed a broken release last night
to fix you can export BOOT_VERSION=2.3.0
and download https://github.com/boot-clj/boot/releases/download/2.3.0/boot.sh
perfect timing 😉
@ska hey and welcome 😉
@martinklepsch: it's about time I join, eh?
i'm gonna update the README with 2.3.0 links
until we get this sorted
@ska: true words. anything specific you want to use boot for?
@martinklepsch: First, I love the claim. Second, just want to generally be informed. So, no, nothing special. Will try to compile mixed clj and java project.
@ska: that will be a breeze, just did that the other day
Nice, setting ENV BOOT_VERSION 2.3.0
in my boot 2.3.0 Dockerfile got it building fine. Works for me. I guess hard-coding that in is probably better any way? Thoughts?
@martinklepsch: hmm, breeze? Now boot fails silently with return code 254 😕
@ska: did you downgrade to 2.3.0?
do you have a boot.properties file in the project dir?
Uhm, I had a REPL a few minutes ago in /tmp now it is not working anymore. So, not project related
@ska did you download the 2.3.0 binary as well?
@ska: you just add them like any other source path, i.e (set-env! :source-paths #{“com/main/bla/src”})
@ska: there’s a javac
task (`boot javac -h`) that can compile them for you.
basically you’ll want a combination of pom
, javac
and jar
— maybe aot
as well
@micha: why do we only want a partial revert?
I’d have thought we fully revert the change and continue in another branch with testing
@micha: so you mean a new binary would fix it and the libs are ok?
so we have a 2.4.2 or do we just override the binaries?
ahhhh!
got it
building and testing now
haha, I thought of him as well
i dunno man it looks legit
dotted i's, crossed t's
@micha: sweet. indeed fixes https://github.com/boot-clj/boot/issues/321
@micha: btw, do things in boot.properties override env vars?
dunno about gradle wrapper, sorry
A thin wrapper supposed to be checked in. Eases installation pain and makes builds reproducible.
@ska: https://github.com/boot-clj/boot/issues/163 — I think now that parts of #300 have been reverted it’s not yet there. Wont be long though I guess
@martinklepsch: Yeah, I read that earlier. That was the reason for me asking, if boot.sh (the Loader) should be checked in now.
@ska: you could check it in. I think the point of #317 is that the binary does not change at all anymore
@micha: what do you think about depending on 1.7 for all the libs? for some reason I can’t get this to build without it: https://github.com/boot-clj/boot/pull/318/files causing weird things:
java.lang.IllegalAccessError: tried to access method clojure.lang.RT.classForNameNonLoading(Ljava/lang/String;)Ljava/lang/Class; from class boot.from.digest$loading__5340__auto____25, compiling:(web.clj:1:1)
I would think not a lot but well… trying one more thing.
will in a sec
@micha: one more thing worked ^
@micha how much did you sleep tonight? 😄
@martinklepsch: i'm down with splitting boot.tmpdir into a separate library btw
@micha: I was thinking the registry stuff could go in there too but fine too if not
Is there any work done on https://github.com/adzerk-oss/boot-test/issues/9? I'd love to be able to use the junit formatter.
my thought was the fileset requires something like tmpregistry in most cases anyways
@micha: with new binary App Version will always be $BOOT_VERSION is that right?
“of boot” as in boot binary right?
k, then everything seems to work fine 👍 nice one!
i'll remove the boot.sh and boot.exe from 2.4.1 release when we are confident the issues are resolved
are these the old ones?
i like having the binaries on the 2.4.0 release because that's where the new regime comes into effect
cool, muddling with releases seems like something we’d want to avoid but in this case
I wouldn’t be surprised, there have been previous occasions where people got old binaries somehow
@tcrawley: thanks for offering your help, I think micha worked it out now: https://github.com/boot-clj/boot/commit/383d282b9858d21e1cfd9e25c88b610009df4615
i was creating a new URLClassLoader instance, loading the uberjar (the one with shimdandy) into it, setting it as TCCL, and then calling boot.App/-main in there via reflection
the fix was using reflection to add the uberjar to the system classloader by exposing the protected add-URL() method via reflection
@micha: i still get the problem with cider using the new boot.sh
oh, wait1
i will run this thing in docker to make sure
yeah i think i was confus
@micha: ah, the issue may be that the shim resets the TCCL to its own CL, so the CL you set as the TCCL would be overwritten?
that sounds like it
the first issue was loader problem where it tried to load clojure classes more than once
@micha: ok i can confirm, it works - totally clean with just the offending ~/.boot/profile.boot
clojure.lang.ExceptionInfo: loader constraint violation:
loader (instance of java/net/URLClassLoader) previously initiated
loading for a different type with name "clojure/lang/Compiler$Expr"
we fixed that in boot clojure code to filter out org.clojure/clojure
from being added dynamically via set-env!
because after that was fixed more subtle issues arose, like this one https://github.com/boot-clj/boot/issues/320
so i get a handle on addURL() for the system cl, make it accessible, then add the app uberjar to it, and call -main via reflection
I'm glad that works. I'm just trying to figure out the cause, since I don't know what's going on either :)
i was thinking maybe shimdandy api needs to be at the tip of the classloader hierarchy?
I've got to go work on something else now, but will let this stew in the back of my head and see if I can figure it out
my pleasure! will do, and feel free to ping me any time with stuff like this, even if I usually don't have an answer :)
fortunately you usually do have an answer 🙌
you have the worst library to support, because people must come to you with the worst problems
Does this look like a sane way to set dependencies at task runtime?
but it will change the dependencies for the pom task, which is what you want there i think
well if it does not actually change the dependencies then aot will break
or not?
The reason I’m exploring this is because when one build needs the jar of another one that hasn’t been built yet it will fail
that sounds very much like how you’d orchestrate lein building interdependent things 😄
i think step 1 is just to continue to use the makefile, but have it call boot in each module instead of lein
when that's working and producing correct jars we can make a build.boot in the main dir that calls runBoot() on all of those
alternatively to multiple runBoot couldn’t we just use pods and pass them the fileset?
when I set BOOT_VERSION to a development build I just made on my machine I get errors that boot.jar
can’t be downloaded from github
is there way to completely blow away boot from an OS X system and reinstall it from scratch?
@peterbak: delete the binary + rm -rf ~/.m2/repository/boot
both right now
trying integrating boot into Makefile as you said, then we can merge and improve from there
thanks @martinklepsch trying that now
it won't try to download it if it's installed in BOOT_HOME/cache/bin/BOOT_VERSION/boot.jar
lol, how can I have a symbol ’boot
in my build.boot?
> boot already refers to: #'boot.core/boot in namespace: boot.user
I know but how can I pass ’boot
to the pom task then?
to build the boot project?
argh damn, sorry 😄
I forgot my task was also named boot 😛
cool, I’ll integrate the thing I have with the make file now
@chrisn it will be soon
Ah, the joy of side effects... I added a dir to resource paths once to get a file into an uberjar, then wanted to get that file out of it again, but it still turned up. After a short detour searching for a clean task, I found that the set-env! was still in effect, because I did not set it back.
Hm, what am I missing? A file was copied to the target-folder because I had a directory in the :resource-paths
. I remove that setting from the call to set-env!
and manually (set-env :resource-paths #{})
. But the file is still in target and gets added to the uberjar.
@ska: you can't un-add resources from the classpath, but you can filter them from the fileset
not being able to remove from the classpath is a jvm limitation we can't work around
we mitigate by making it possible/easy to create new classpaths, aka pods
so what you want is to filter from the fileset, this is the set of things that will show up in target. you can check out the sift
task
you can use it to filter out items in the fileset by regex
if you look around the build.boots for cljsjs packages, you can see many usages https://github.com/cljsjs/packages
on those rare cases I can also restart the JVM. Would that help? Would that remove the file from target dir?
it will reset the fileset which will probably lead to the result you want
also removing a directory won't trigger the watch task, so maybe you need to manually trigger a build
> i dunno, how many people are using boot with 1.6? we actually had to lock down one of our components to 1.6 because it was failing with some weird exception, iirc but otherwise are on 1.7 everywhere else
I think it would be best to keep 1.6 compatibility at least until 1.8 is released
Should 2.4.1 be working now?
@juhoteperi: yep!
Okay, started working after redownloading it
@micha: regarding the files which end up in the JAR or not.... I need to play with it some more. Will come back if I think something is not as it should be.
Just sent a PR to boot-test adding junit formatter support. Feedback welcome https://github.com/adzerk-oss/boot-test/pull/11
checking the build error... not sure yet if it failed because of the failing test (that I put there on purpose) or something else
It's at least using historical version of boot, pre 2.0 release
Updating .travis.yml should help and would also be good idea to update the dependency in build.boot
@nberger: Also, 2.4.1 would probably be preferred as 2.4.0 is quite broken
how can i get the built-in boot web
task to reload its serve
function when code is changed?
@esp1: the web task only makes a web.xml and injects some java, it doesn't start any servers... what are you trying to do?
oh ok - yeah that task is handy if you're deploying as a WAR file and want to run a war locally
another option that doesn't imply the web task is https://github.com/pandeiro/boot-http
@alandipert: oops, seems like boot.sh is not available for download in the 2.4.1 release, so the boot-test build is still failing 😕
@nberger: i'll fix
@alandipert: cool, thx
thx btw
@nberger: would you mind outputting the junit reports to the fileset instead?
at least, that seems more future proof... subsequent tasks could process the xml and do things with it
@alandipert: Yes, sounds like a good idea, I'll try to do that.
thanks!
hello guys, if I do boot -h
in a Mac machine I don't see any output
what can it be?
@richiardiandrea: what’s the output of boot -V
?
try rm -rf ~/.boot/cache/bin
boot -V
#
#Tue Oct 27 20:46:26 CET 2015
BOOT_CLOJURE_VERSION=1.6.0
BOOT_VERSION=2.4.1
#App version: 2.0.0
oh. you need to download the latest executable
boot.sh
: https://github.com/boot-clj/boot/releases/tag/2.4.0
ah, I installed it with brew
lol ok
brew PR is outstanding but if you want to stick with brew you can set $BOOT_VERSION
to 2.2.0
or so and upgrade boot via brew
2.0.0 is pretty old but I think 2.2.0 or so should be on homebrew
that's good then, will try now
no atm is 2.0.0
but whatever works 😄
I see a boot 2.2.0 in homebrew — maybe you need to update brew itself?
like brew update
I mean..
ok i am trying without brew, it feels safer
i downloaded boot.sh and copied in /usr/local/bin and it downloads the right jar
but still nothing
#
#Tue Oct 27 20:56:25 CET 2015
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_VERSION=2.4.1
BOOT_CLOJURE_VERSION=1.6.0
#App version: 2.4.1
does it require 1.7 ?
and how to update it?
shall I dowload in .m2 clojure 1.7 ?
@richiardiandrea: you can edit ~/.boot/boot.properties
@richiardiandrea: what is the result of echo $?
after you run boot -h
and it returns nothing?
on boot repl
as well, same return value from the script
can you once again do rm -rf ~/.boot/cache/bin
please?
ok by changing version in ~/.boot/boot.properties
it works
@richiardiandrea: what version did you change? clojure?
i am reverting to 1.6 and try your stuff
cleared cache and return of it is again 254
i am going to keep 1.7 for now then
can reproduce, thanks @richiardiandrea!
great! if you want I can open an issue
yep exactly
hi. i’ve just upgraded boot to 2.4.1 and seems like it totally stopped working (eg. boot repl does completely nothing). any ideat wha happened?
@michal: boot -V
please
@alandipert: i found my issue with reloading. i had relocated my source into a dir named “client/src/clj”. it looks like reload only works for source dirs that start with “src/"
#
#Tue Oct 27 21:12:34 CET 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.4.1
#App version: 2.0.0
@esp1: ah! i feel like i've run into that before myself and never figured it out
@michal: your binary is outdated, how did you install boot? (you can download the new binary from https://github.com/boot-clj/boot/releases/tag/2.4.0
i took boot.sh from https://github.com/boot-clj/boot#install
@alandipert: is this a bug in boot-http? or boot?
@michal: that is strange the checksum should be 9dd9f0ae594b1658fe79477ceb492289
, maybe check that?
@esp1: boot-http. https://github.com/pandeiro/boot-http/blob/master/src/pandeiro/boot_http/impl.clj#L66 https://ring-clojure.github.io/ring/ring.middleware.reload.html
@richiardiandrea: can you paste the output of md5sum
of your boot.sh file?
@esp1: Wrap-reload defaults to src. Boot-http should pass in options: {:dirs (boot/get-env :directories)\
yup, checksum is identical:
MD5 (/usr/local/bin/boot) = 9dd9f0ae594b1658fe79477ceb492289
@juhoteperi: cool. do you want to post the pull request or should i?
@esp1: You are welcome to do it. I have enough to do already .)
@michal, hm. only idea I now have is the boot
you’re calling is not /usr/local/bin/boot
@martinklepsch: ok, i will try to download it again. give me a sec.
@michal: you already have the right file as far as I can see
@michal I assume which boot
= /usr/local/bin/boot
?
@esp1: Note: wrap-reload is used inside a pod where boot.core
is not available, you need to call get-env in the task and pass the value to boot-http.impl/server
call.
~ % md5 /usr/local/bin/boot
MD5 (/usr/local/bin/boot) = 9dd9f0ae594b1658fe79477ceb492289
~ % /usr/local/bin/boot repl
~ %
@juhoteperi: good call, thx
@micha: but wouldn’t that be shown when he runs boot -V
?
#
#Tue Oct 27 21:12:34 CET 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.4.1
#App version: 2.0.0
^ This is what @michal posted earlier
phew 😄
@micha: bug, that it prints the wrong BOOT_VERSION in boot -V?
@juhoteperi: i submitted the pull request but looks like it failed ci. error 254 looks suspiciously like the boot version issue above. https://github.com/pandeiro/boot-http/pull/27
@esp1: Updating version of boot.sh in .travis.yml would probably help
@juhoteperi: done. ci passed cleanly this time. i added a boot.properties
file as well to pin the version. thx!
^ if anyone could checkout that branch and run boot base —uberjar
that would be great, there’s a magic jar file appearing!
@juhoteperi: do you think changelog should be updated for 2.4.1 & 2.4.2 as well? guess it should?
@micha: do you want to update for 2.4.2? not sure I could describe what was done
but this is something else no? https://github.com/boot-clj/boot/commit/270ec3d85d41766c5d3a72bb4e6ef0f704630d1d
throwing an exception dumps you out of the main method, and then the JVM exits before the stack trace can be flushed from the sdtout buffers
Ok I’ll add this
and there we go: https://github.com/Homebrew/homebrew/commit/0860817123d96416844641cddd3628e3a66291b1
@nberger: btw https://github.com/alandipert/boot-jasmin/blob/master/src/alandipert/boot_jasmin.clj is a little example of doing work in a pod and outputting to a tmp-dir
@alandipert: Cool, I'll check it out, thx
@alandipert: Is it important that tgt
is created in the outer let
there? Or could it be created in the inner body?
it's idiomatic to create it in the outer layer and re-use it
but no, not important really
i can't even remember why we do it that way everywhere
probably mostly just to show how the outermost let is the part of the task where one initializes resources
if you allocate resources in the middleware layer then those resources must always be allocated in pipeline order
if you do it in the outermost let then someone could create the tasks in a different order than they compose them in the pipeline
Sure. Btw, the branch is working in my machine, so I guess I'm not doing it that wrong with the fileset 😛. I think it's right. But I'm trying this on a project in a CircleCI build and the files are not being copied to the target dir, and I'm not sure why
So, from what you are saying, it's better to allocate in the innermost let, or I'm not following you?
Doing it in the innermost would make it to not hold that state, might be more memory-friendly if that's an issue
Ok, now I understand what's happening... when there's a test failure, boot-test throws an exception, so the pipeline stops processing, etc... of course that makes my commit!
call to not happen, and target-path
is not even created. Any idea?
the issue can be reproduced by introducing a test failure in adzerk.boot-test.test
then running boot test
As we are here, I'd say that I don't love the stacktrace we always get when there's a test failure... but I guess an exception is the only way to stop the pipeline? I wonder if there's some way to make the throw
on failing tests to be optional?
@nberger: hey, yeah - thre are several ways to do it
@nberger: another way that comes to mind is have a separate task that picks up the test report and maybe throws, or maybe just prints output
@nberger: i think what it should do depends on the context; like dev, you just want to see passing results; or ci, where you want the build to fail
@nberger: maybe the way is 2 tasks - one which runs tests and adds a report to the fileset, and another downstream task which looks for the report and throws or prints it depending on flag