This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # asami (1)
- # aws (2)
- # babashka (5)
- # babashka-sci-dev (162)
- # beginners (68)
- # biff (1)
- # calva (26)
- # circleci (4)
- # clj-kondo (5)
- # cljs-dev (7)
- # clojure (84)
- # clojure-europe (15)
- # clojure-uk (1)
- # clojured (2)
- # clojurescript (19)
- # conjure (1)
- # datomic (5)
- # emacs (2)
- # graalvm (20)
- # honeysql (6)
- # improve-getting-started (2)
- # kaocha (3)
- # lsp (31)
- # off-topic (7)
- # pathom (7)
- # releases (1)
- # shadow-cljs (1)
- # spacemacs (1)
- # vim (30)
@borkdude do you remember why are we doing https://github.com/babashka/pod-babashka-fswatcher/issues/12#issuecomment-1119306799 ? call
WriteInvokeResponse and not
WriteErrorResponse? Its been a while for me and I'm failing to recollect 😛 Also since its not reproducible, should i look into it?
@rahul080327 The way I would fix this is based on tests. Write a test that reproduces the error, fix it, while ensuring the other tests also works. The exact details: dunno :)
yeah the person who reported this cant seem to come up with it anymore after a machine restart it seems
I'll ask for a repro then think about it
Are Actions on sci upto date?
okay looking into it now
whats the node version needed for node tests?
@rahul080327 It seems to be the macOS build that wasn't running. I'm not sure if it's just that
yeah adding in the matrix to the native one now
The thing that we need CircleCI specifically is: • more memory (8gb. only important for babashka) • aarch64 builds (important for babashka, pods and clj-kondo) macOS builds we can do on Github Actions too (although it would be way slower) Windows we've always done on Appveyor (which in hindsight is good to spread the risk)
yeah afaik action runners are 8G too, not sure about aarch64
this is the current one
Hardware specification for Windows and Linux virtual machines: 2-core CPU 7 GB of RAM memory 14 GB of SSD disk space Hardware specification for macOS virtual machines: 3-core CPU 14 GB of RAM memory 14 GB of SSD disk space
is aarch64 blocked on circle too?
no, at least not yet... I'm not sure if macos was just blocked because of macos or because it was the last job to run
yeah I'll just catch the actions yamls up, be prepped
clojure-lsp produces aarch64 via qemu, which is hell slow, the job takes more than an hour, which isn't something I would want
could also build manually on m1 macos inside docker, but also something I want to avoid
could also run self-hosted Github actions builds inside my PC maybe, but then I'd have my PC on all day ;)
yeah the qemu path could be really slow
yeah this is just my paranoid-infra-goes-to-shit mind kicking in
test-self-hosted in actions = plank in circle?
yeah im seeing a
test-self-hosted job there
its seen more updates than bb at least, going by commits 😛
Oh, bb tasks are really paying off here, since it's the same thing no matter where you run it
yeah its pretty nice
yeah im just adding the jdk 11, clj cli, node tooling etc
and the native matrix
so im planning to use the:
- name: Install clojure tools uses: DeLaGuardo/[email protected] with: cli: 184.108.40.2063 lein: 2.9.3 bb: 0.8.2
reduce some extra installs
- name: Prepare java uses: actions/[email protected] with: distribution: 'adopt-hotspot' java-version: '11'
can leave it out if you want, just do the native matrix on mac and ubuntu?
was installing the clojure cli as circle had it too
would be more than happy to drop stuff 😄
yeah will get there
so clojure cli not needed?
I thought it wasn't needed because bb tasks + (clojure ...) but I see it's still calling
script/test/jvm which calls the clojure CLI. Let's changre as little as possible to all of this and just focus on getting it to work
almost done here, raise the PR and will go there
ah the the deploy step wont work
yeah, will leave a TODO
actions bits look good on https://github.com/babashka/sci/pull/722
Talking to https://twitter.com/IAmJerdog in DM now, he's looking into it!
Btw, the "quit job if only .md file has changed" has been on my list for ages now too
ive used something like https://github.com/tj-actions/changed-files for actions
big monorepos at work
this with the
if: ... directive
can have a bb script for that? 😄
yeah more bootstrapping test for the bb repo
Maybe we could just run that code using clojure itself when bb hasn't bootstrapped yet
yeah i think all these and maybe the compile could be in tools.build somehow?
22.1.0 is the correct graal version for bb right?
ah right, appveyor had 6gb. bb barely builds there, it spends a lot of time in GC ;). the only difference with github is that github has 1gb extra. On Circle we have 8gb + 4 CPU instead of 2 on Github
yeah its not the best but more as a backup
maybe we can get some credits on Exoscale and I can have a build cluster running there 😛
clojure all the way
we can have a think if that can be used
I might be porting my personal VPS to them, but it's only 100 EUR a year or so at my current provider, so I wasn't really in a hurry to do so
I could also just start paying for CircleCI, I think it's somewhere between 300-400 dollars a month
as long as I got enough sponsors ... and if not, I should charge money for the binaries or so
yeah theres ways around it, maybe similar to clojars, we can get some hosted infra for things
right, could move all the lower resource stuff to github actions and only run the critical things on circle
yeah once actions is at parity, i can think of dividing up the the things
or graal finally lands cross compiling 😛
yeah, also building in M1 docker isnt too bad, could be used as a fallback
but yeah same story on actions, no M1
.circleci/script/release safe to run on actions too?
turning actions back on
tried pulling some tricks with the matrix since the code was so out of date, lets see if it all works. should be a big reduction in yaml if it does
actions doesnt seem to be triggered
ah push only on master
its been a while 😄
yeah probably some more fixing needed
yes, last time I enabled github actions on babashka was actually during ClojureD 2020
@rahul080327 the buildx stuff, would that also work on github actions?
yeah theres a setup for that too 😄
the actions yaml is like half the circle one, although no aarch64
best place would be the workflows at the end to disable circle right?
right, cancelling the job now too
yeah didnt change any of the workflows in actions, will have a better think
yeah, I remember now, the initial version was contributed by someone who already knew github actions and I think he wanted to save the uberjar for other jobs or so. similar discussion that we had for circleci recently
I found a conversation with Marc in which he enabled macOS builds for 2 years on 2020 May 7th... so this explains it
actually the macos build are the best candidates to move to github actions since github actions has 14gb of memory there
yeah sounds like a good plan, im thinking lets get it to parity and disable parts of it
not too bad on linux
52.3s (17.5% of total time) in 108 GCs | Peak RSS: 5.84GB | CPU load: 1.92 Finished generating 'bb' in 4m 57s.
The xmx is very close to the max here: BABASHKA_XMX: -J-Xmx6500m Could be close to an OOM error if it was bumped even higher
yeah lets see if it OOMs
yeah i messed up the condition, will push after this
shouldve been the not of the other but i was oversmart
@rahul080327 we could use the official graalvm github action which has musl support
no idea what
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/./libstdc++.a(cp-demangle.o): in function `d_print_comp_inner': (.text+0x5a04): undefined reference to `__sprintf_chk' /usr/bin/ld: (.text+0x6219): undefined reference to `__sprintf_chk' /usr/bin/ld: (.text+0x6764): undefined reference to `__sprintf_chk' /usr/bin/ld: (.text+0x6bea): undefined reference to `__sprintf_chk' /usr/bin/ld: (.text+0x6de2): undefined reference to `__sprintf_chk'
interesting error: https://github.com/babashka/babashka/runs/6337178092?check_suite_focus=true will continue tomorrow