This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (1)
- # beginners (5)
- # boot (46)
- # cider (6)
- # cljs-dev (421)
- # cljsrn (74)
- # clojure (77)
- # clojure-greece (1)
- # clojure-italy (7)
- # clojure-russia (12)
- # clojure-serbia (42)
- # clojure-sg (1)
- # clojure-spec (10)
- # clojure-uk (38)
- # clojurescript (40)
- # core-async (14)
- # data-science (1)
- # datomic (18)
- # emacs (2)
- # events (1)
- # garden (4)
- # gorilla (4)
- # graphql (5)
- # hoplon (69)
- # luminus (1)
- # lumo (1)
- # off-topic (31)
- # om (31)
- # om-next (2)
- # overtone (3)
- # pedestal (1)
- # precept (4)
- # re-frame (23)
- # reagent (2)
- # remote-jobs (1)
- # ring-swagger (23)
- # rum (7)
- # spacemacs (7)
- # sql (4)
- # unrepl (9)
- # untangled (5)
- # vim (11)
- # yada (5)
Best way to check if a resource has been updated & wether to run a task? Timestamp in an atom?
@minikomi common pattern is to store the fileset of the previous invocation and compare files’ checksums
thanks, will look it up boot -garden was a good example of tracking when namespaces change, using ns-tracker, but was trying to find a good resources-change example.
https://github.com/boot-clj/boot/wiki/Running-Boot-on-CI-systems#circleci-v2 mentions that the "inotify watch limits" are solved. However I'm still seeing them occasionally. I'm optimistically hoping I'm doing something wrong I have tweaked the template slightly). Any suggestions?
Hmm, odd. Something to keep an eye on I guess... it seems to happen sporadically. So it could be something else.
j/w, but did you need to add
apk update && apk add git openssh to get circleci to quit complaining about checkout?
Cljsjs has already ran at least hundreds of builds with new configuration and previously every 25 build or something like that failed due to inotify limit
I'm running alpine version in Jenkins but Git checkout is running outside of docker container there
makes sense that the debian image would have git/ssh already, and alpine would definitely not.
Hmm yes, perhaps it will be good idea to change the example as in CircleCI one always wants to have git available
https://github.com/docker-library/openjdk/blob/415b0cc42d91ef5d70597d8a24d942967728242b/8-jdk/Dockerfile#L7 https://github.com/docker-library/openjdk/blob/415b0cc42d91ef5d70597d8a24d942967728242b/8-jdk/alpine/Dockerfile#L7 No Git ot anything available: https://hub.docker.com/_/alpine/
apk update && apk add git openssh works. Is the lightness worth the extra line in config (and does it offset the cost?)
No, using existing image, even if larger, is probably faster than having to install new software
I think there's something called
multiboot hanging around somewhere. Might be lying though.
good enough for what I need I think, we're trying to run two watch tasks without having to start two jvm processes
Or well, tasks, but you have to provide tasks as strings... I don't see what is the reason behind that
apparently because it runs boot-in-boot, i.e. in a separate pod (I'm just saying words here that I read somewhere ;))
I remember writting
parallel higher order function, which runs given task functions parallel, but I'm not sure where that is.
oh neat, runcommands works on the existing fileset. I expected it to run on a new one for some reason.
so apparently somewhere here had already tried
runcommands, and it crashed the JVM due to concurrent modifications in boot's tmp directories
(deftask multi-task  (let [tasks [(future (boot (...))) (future (boot (...)))]] (run! deref tasks)))
runcommands is the way to run tasks in parallel, but of course that does not protect from concurrency issues
so you have to implement your own locking/compare and swap if some resource is shared